<!DOCTYPE HTML>
<html lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>最终: OpenID Connect Core 1.0 incorporating errata set 1</title>

    <meta name="description" content="OpenID Connect Core 1.0 incorporating errata set 1">
    <meta name="generator" content="xml2rfc v1.37pre1 (http://xml.resource.org/)">
    <style type="text/css"><!--
    body {
        font-family: verdana, charcoal, helvetica, arial, sans-serif;
        font-size: small;
        color: #000;
        background-color: #FFF;
        margin: 2em;
    }

    h1, h2, h3, h4, h5, h6 {
        font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
        font-weight: bold;
        font-style: normal;
    }

    h1 {
        color: #900;
        background-color: transparent;
        text-align: right;
    }

    h3 {
        color: #333;
        background-color: transparent;
    }

    td.RFCbug {
        font-size: x-small;
        text-decoration: none;
        width: 30px;
        height: 30px;
        padding-top: 2px;
        text-align: justify;
        vertical-align: middle;
        background-color: #000;
    }

    td.RFCbug span.RFC {
        font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
        font-weight: bold;
        color: #666;
    }

    td.RFCbug span.hotText {
        font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
        font-weight: normal;
        text-align: center;
        color: #FFF;
    }

    table.TOCbug {
        width: 30px;
        height: 15px;
    }

    td.TOCbug {
        text-align: center;
        width: 30px;
        height: 15px;
        color: #FFF;
        background-color: #900;
    }

    td.TOCbug a {
        font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
        font-weight: bold;
        font-size: x-small;
        text-decoration: none;
        color: #FFF;
        background-color: transparent;
    }

    td.header {
        font-family: arial, helvetica, sans-serif;
        font-size: x-small;
        vertical-align: top;
        width: 33%;
        color: #FFF;
        background-color: #666;
    }

    td.author {
        font-weight: bold;
        font-size: x-small;
        margin-left: 4em;
    }

    td.author-text {
        font-size: x-small;
    }

    /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
    a.info {
        /* This is the key. */
        position: relative;
        z-index: 24;
        text-decoration: none;
    }

    a.info:hover {
        z-index: 25;
        color: #FFF;
        background-color: #900;
    }

    a.info span {
        display: none;
    }

    a.info:hover span.info {
        /* The span will display just on :hover state. */
        display: block;
        position: absolute;
        font-size: smaller;
        top: 2em;
        left: -5em;
        width: 15em;
        padding: 2px;
        border: 1px solid #333;
        color: #900;
        background-color: #EEE;
        text-align: left;
    }

    a {
        font-weight: bold;
    }

    a:link {
        color: #900;
        background-color: transparent;
    }

    a:visited {
        color: #633;
        background-color: transparent;
    }

    a:active {
        color: #633;
        background-color: transparent;
    }

    p {
        margin-left: 2em;
        margin-right: 2em;
    }

    p.copyright {
        font-size: x-small;
    }

    p.toc {
        font-size: small;
        font-weight: bold;
        margin-left: 3em;
    }

    table.toc {
        margin: 0 0 0 3em;
        padding: 0;
        border: 0;
        vertical-align: text-top;
    }

    td.toc {
        font-size: small;
        font-weight: bold;
        vertical-align: text-top;
    }

    ol.text {
        margin-left: 2em;
        margin-right: 2em;
    }

    ul.text {
        margin-left: 2em;
        margin-right: 2em;
    }

    li {
        margin-left: 3em;
    }

    /* RFC-2629 <spanx>s and <artwork>s. */
    em {
        font-style: italic;
    }

    strong {
        font-weight: bold;
    }

    dfn {
        font-weight: bold;
        font-style: normal;
    }

    cite {
        font-weight: normal;
        font-style: normal;
    }

    tt {
        color: #036;
    }

    tt, pre, pre dfn, pre em, pre cite, pre span {
        font-family: "Courier New", Courier, monospace;
        font-size: small;
    }

    pre {
        text-align: left;
        padding: 4px;
        color: #000;
        background-color: #CCC;
    }

    pre dfn {
        color: #900;
    }

    pre em {
        color: #66F;
        background-color: #FFC;
        font-weight: normal;
    }

    pre .key {
        color: #33C;
        font-weight: bold;
    }

    pre .id {
        color: #900;
    }

    pre .str {
        color: #000;
        background-color: #CFF;
    }

    pre .val {
        color: #066;
    }

    pre .rep {
        color: #909;
    }

    pre .oth {
        color: #000;
        background-color: #FCF;
    }

    pre .err {
        background-color: #FCC;
    }

    /* RFC-2629 <texttable>s. */
    table.all, table.full, table.headers, table.none {
        font-size: small;
        text-align: center;
        border-width: 2px;
        vertical-align: top;
        border-collapse: collapse;
    }

    table.all, table.full {
        border-style: solid;
        border-color: black;
    }

    table.headers, table.none {
        border-style: none;
    }

    th {
        font-weight: bold;
        border-color: black;
        border-width: 2px 2px 3px 2px;
    }

    table.all th, table.full th {
        border-style: solid;
    }

    table.headers th {
        border-style: none none solid none;
    }

    table.none th {
        border-style: none;
    }

    table.all td {
        border-style: solid;
        border-color: #333;
        border-width: 1px 2px;
    }

    table.full td, table.headers td, table.none td {
        border-style: none;
    }

    hr {
        height: 1px;
    }

    hr.insert {
        width: 80%;
        border-style: none;
        border-width: 0;
        color: #CCC;
        background-color: #CCC;
    }

    --></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0">
    <tbody>
    <tr>
        <td>
            <table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
                <tbody>
                <tr>
                    <td class="header">Final</td>
                    <td class="header">N. Sakimura</td>
                </tr>
                <tr>
                    <td class="header">&nbsp;</td>
                    <td class="header">NRI</td>
                </tr>
                <tr>
                    <td class="header">&nbsp;</td>
                    <td class="header">J. Bradley</td>
                </tr>
                <tr>
                    <td class="header">&nbsp;</td>
                    <td class="header">Ping Identity</td>
                </tr>
                <tr>
                    <td class="header">&nbsp;</td>
                    <td class="header">M. Jones</td>
                </tr>
                <tr>
                    <td class="header">&nbsp;</td>
                    <td class="header">Microsoft</td>
                </tr>
                <tr>
                    <td class="header">&nbsp;</td>
                    <td class="header">B. de Medeiros</td>
                </tr>
                <tr>
                    <td class="header">&nbsp;</td>
                    <td class="header">Google</td>
                </tr>
                <tr>
                    <td class="header">&nbsp;</td>
                    <td class="header">C. Mortimore</td>
                </tr>
                <tr>
                    <td class="header">&nbsp;</td>
                    <td class="header">Salesforce</td>
                </tr>
                <tr>
                    <td class="header">&nbsp;</td>
                    <td class="header">November 8, 2014</td>
                </tr>
                </tbody>
            </table>
        </td>
    </tr>
    </tbody>
</table>
<h1><br>OpenID Connect Core 1.0 incorporating errata set 1</h1>

<h3>摘要</h3>

<p>
    OpenID Connect 1.0 是一个在OAuth 2.0之上的简单身份认证协议. 它允许客户端(Client)在一个授权服务器(Authorization Server)上执行认证(authentication),
    并验证最终用户(End-User)的身份, 同时以互操作性和类似REST方式获取最终用户的基本配置信息.
</p>

<p>
    此规范定义了核心的OpenID Connect功能:
    身份认证构建在OAuth 2.0之上并且使用Claims来传递最终用户(End-User)相关信息.
    它同时描述安全与隐私考虑使用OpenID Connect.

</p><a name="toc"></a><br>
<hr>
<h3>目录</h3>

<p class="toc">
    <a href="#Introduction">1.</a>&nbsp;
    介绍<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#rnc">1.1.</a>&nbsp;
    必要的符号与约定<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#Terminology">1.2.</a>&nbsp;
    术语<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#Overview">1.3.</a>&nbsp;
    概述<br>
    <a href="#IDToken">2.</a>&nbsp;
    ID Token<br>
    <a href="#Authentication">3.</a>&nbsp;
    认证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#CodeFlowAuth">3.1.</a>&nbsp;
    使用授权码(Authorization Code)认证流程<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#CodeFlowSteps">3.1.1.</a>&nbsp;
    授权码(Authorization Code)认证流程步骤<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AuthorizationEndpoint">3.1.2.</a>&nbsp;
    授权端点(Authorization Endpoint)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AuthRequest">3.1.2.1.</a>&nbsp;
    认证请求<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AuthRequestValidation">3.1.2.2.</a>&nbsp;
    认证请求的验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#Authenticates">3.1.2.3.</a>&nbsp;
    授权服务器认证最终用户(End-User)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#Consent">3.1.2.4.</a>&nbsp;
    授权服务器获取最终用户(End-User)同意/授权<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AuthResponse">3.1.2.5.</a>&nbsp;
    成功的认证响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AuthError">3.1.2.6.</a>&nbsp;
    错误的认证响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AuthResponseValidation">3.1.2.7.</a>&nbsp;
    认证响应的验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#TokenEndpoint">3.1.3.</a>&nbsp;
    Token端点(Endpoint)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#TokenRequest">3.1.3.1.</a>&nbsp;
    Token请求<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#TokenRequestValidation">3.1.3.2.</a>&nbsp;
    Token请求的验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#TokenResponse">3.1.3.3.</a>&nbsp;
    成功的Token响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#TokenErrorResponse">3.1.3.4.</a>&nbsp;
    错误的Token响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#TokenResponseValidation">3.1.3.5.</a>&nbsp;
    Token请求的验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#CodeIDToken">3.1.3.6.</a>&nbsp;
    ID Token<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#IDTokenValidation">3.1.3.7.</a>&nbsp;
    ID Token 验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#CodeFlowTokenValidation">3.1.3.8.</a>&nbsp;
    Access Token 验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ImplicitFlowAuth">3.2.</a>&nbsp;
    使用隐式(Implicit)认证流程<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitFlowSteps">3.2.1.</a>&nbsp;
    隐式(Implicit)认证流程步骤<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitAuthorizationEndpoint">3.2.2.</a>&nbsp;
    授权端点(Endpoint)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitAuthRequest">3.2.2.1.</a>&nbsp;
    认证请求<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitValidation">3.2.2.2.</a>&nbsp;
    认证请求的验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitAuthenticates">3.2.2.3.</a>&nbsp;
    授权服务器认证最终用户(End-User)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitConsent">3.2.2.4.</a>&nbsp;
    授权服务器获取最终用户(End-User)同意/授权<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitAuthResponse">3.2.2.5.</a>&nbsp;
    成功的认证响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitAuthError">3.2.2.6.</a>&nbsp;
    错误的认证响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitCallback">3.2.2.7.</a>&nbsp;
    重定向URI的处理<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitAuthResponseValidation">3.2.2.8.</a>&nbsp;
    认证响应的验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitTokenValidation">3.2.2.9.</a>&nbsp;
    Access Token 验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitIDToken">3.2.2.10.</a>&nbsp;
    ID Token<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitIDTValidation">3.2.2.11.</a>&nbsp;
    ID Token 验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#HybridFlowAuth">3.3.</a>&nbsp;
    使用混合(Hybrid)认证流程<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridFlowSteps">3.3.1.</a>&nbsp;
    混合(Hybrid)认证流程步骤<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridAuthorizationEndpoint">3.3.2.</a>&nbsp;
    授权端点(Endpoint)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridAuthRequest">3.3.2.1.</a>&nbsp;
    认证请求<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridValidation">3.3.2.2.</a>&nbsp;
    认证请求验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridAuthenticates">3.3.2.3.</a>&nbsp;
    授权服务器认证最终用户(End-User)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridConsent">3.3.2.4.</a>&nbsp;
    授权服务器获取最终用户(End-User)同意/授权<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridAuthResponse">3.3.2.5.</a>&nbsp;
    成功的认证响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridAuthError">3.3.2.6.</a>&nbsp;
    错误的认证响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridCallback">3.3.2.7.</a>&nbsp;
    重定向URI的处理<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridAuthResponseValidation">3.3.2.8.</a>&nbsp;
    认证响应的验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridTokenValidation">3.3.2.9.</a>&nbsp;
    Access Token 验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#CodeValidation">3.3.2.10.</a>&nbsp;
    授权码的验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridIDToken">3.3.2.11.</a>&nbsp;
    ID Token<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridIDTValidation">3.3.2.12.</a>&nbsp;
    ID Token 验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridTokenEndpoint">3.3.3.</a>&nbsp;
    Token端点(Endpoint)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridTokenRequest">3.3.3.1.</a>&nbsp;
    Token 请求<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridTokenRequestValidation">3.3.3.2.</a>&nbsp;
    Token 请求的验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridTokenResponse">3.3.3.3.</a>&nbsp;
    成功的Token响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridTokenErrorResponse">3.3.3.4.</a>&nbsp;
    错误的Token响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridTokenResponseValidation">3.3.3.5.</a>&nbsp;
    Token响应的 验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridIDToken2">3.3.3.6.</a>&nbsp;
    ID Token<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridIDTValidation2">3.3.3.7.</a>&nbsp;
    ID Token 验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridAccessToken2">3.3.3.8.</a>&nbsp;
    Access Token<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#HybridTokenValidation2">3.3.3.9.</a>&nbsp;
    Access Token 验证<br>
    <a href="#ThirdPartyInitiatedLogin">4.</a>&nbsp;
    从第三方(Third Party)发起登录<br>
    <a href="#Claims">5.</a>&nbsp;
    Claims<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#StandardClaims">5.1.</a>&nbsp;
    标准 Claims<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AddressClaim">5.1.1.</a>&nbsp;
    地址 Claim<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AdditionalClaims">5.1.2.</a>&nbsp;
    附加的 Claims<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ClaimsLanguagesAndScripts">5.2.</a>&nbsp;
    Claims 语言与脚本(Scripts)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#UserInfo">5.3.</a>&nbsp;
    UserInfo Endpoint<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#UserInfoRequest">5.3.1.</a>&nbsp;
    UserInfo 请求<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#UserInfoResponse">5.3.2.</a>&nbsp;
    成功的 UserInfo 响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#UserInfoError">5.3.3.</a>&nbsp;
    UserInfo 错误响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#UserInfoResponseValidation">5.3.4.</a>&nbsp;
    UserInfo Response 验证<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ScopeClaims">5.4.</a>&nbsp;
    请求 Claims 使用 Scope 值<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ClaimsParameter">5.5.</a>&nbsp;
    请求 Claims 使用 "claims" 请求参数<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#IndividualClaimsRequests">5.5.1.</a>&nbsp;
    特殊的 Claims 请求<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#acrSemantics">5.5.1.1.</a>&nbsp;
    请求时的 "acr" Claim<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#IndividualClaimsLanguages">5.5.2.</a>&nbsp;
    特殊的 Claims 时的语言与脚本<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ClaimTypes">5.6.</a>&nbsp;
    Claim 类型<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#NormalClaims">5.6.1.</a>&nbsp;
    正常的 Claims<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AggregatedDistributedClaims">5.6.2.</a>&nbsp;
    单独的和分布式 Claims<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AggregatedExample">5.6.2.1.</a>&nbsp;
    单独的 Claims 示例<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#DistributedExample">5.6.2.2.</a>&nbsp;
    分布式 Claims 示例<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ClaimStability">5.7.</a>&nbsp;
    Claim的稳定性与唯一性<br>
    <a href="#JWTRequests">6.</a>&nbsp;
    通过请求参数传递 JWT<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#RequestObject">6.1.</a>&nbsp;
    通过值(Value)传递请求对象<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#RequestParameter">6.1.1.</a>&nbsp;
    请求时使用"request"请求参数<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#RequestUriParameter">6.2.</a>&nbsp;
    通过引用(Reference)传递请求对象<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#CreateRequestUri">6.2.1.</a>&nbsp;
    URL 引用请求对象<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#UseRequestUri">6.2.2.</a>&nbsp;
    请求时使用"request_uri"请求参数<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#GetRequestUri">6.2.3.</a>&nbsp;
    授权服务器读取(Fetches)请求对象<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#RequestUriRationale">6.2.4.</a>&nbsp;
    "request_uri" 理论基础<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#JWTRequestValidation">6.3.</a>&nbsp;
    验证 JWT-基于请求<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#EncryptedRequestObject">6.3.1.</a>&nbsp;
    加密请求对象<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#SignedRequestObject">6.3.2.</a>&nbsp;
    签名请求对象<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#RequestParameterValidation">6.3.3.</a>&nbsp;
    请求参数的生成(Assembly)与验证<br>
    <a href="#SelfIssued">7.</a>&nbsp;
    Self-Issued OpenID Provider<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#SelfIssuedDiscovery">7.1.</a>&nbsp;
    Self-Issued OpenID Provider Discovery<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#SelfIssuedRegistration">7.2.</a>&nbsp;
    Self-Issued OpenID Provider Registration<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#RegistrationParameter">7.2.1.</a>&nbsp;
    Providing Information with the "registration" Request Parameter<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#SelfIssuedRequest">7.3.</a>&nbsp;
    Self-Issued OpenID Provider Request<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#SelfIssuedResponse">7.4.</a>&nbsp;
    Self-Issued OpenID Provider Response<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#SelfIssuedValidation">7.5.</a>&nbsp;
    Self-Issued ID Token 验证<br>
    <a href="#SubjectIDTypes">8.</a>&nbsp;
    Subject Identifier 类型<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#PairwiseAlg">8.1.</a>&nbsp;
    成对的鉴别(Identifier)算法<br>
    <a href="#ClientAuthentication">9.</a>&nbsp;
    客户端(Client)认证<br>
    <a href="#SigEnc">10.</a>&nbsp;
    签名和加密<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#Signing">10.1.</a>&nbsp;
    签名<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#RotateSigKeys">10.1.1.</a>&nbsp;
    非对称的签名密钥循环(Rotation)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#Encryption">10.2.</a>&nbsp;
    加密<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#RotateEncKeys">10.2.1.</a>&nbsp;
    非对称的加密密钥循环(Rotation)<br>
    <a href="#OfflineAccess">11.</a>&nbsp;
    离线访问<br>
    <a href="#RefreshTokens">12.</a>&nbsp;
    使用 Refresh Tokens<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#RefreshingAccessToken">12.1.</a>&nbsp;
    Refresh 请求<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#RefreshTokenResponse">12.2.</a>&nbsp;
    成功的 Refresh 响应<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#RefreshErrorResponse">12.3.</a>&nbsp;
    错误的 Refresh 响应<br>
    <a href="#Serializations">13.</a>&nbsp;
    序列化<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#QuerySerialization">13.1.</a>&nbsp;
    查询字符(Query String)序列化<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#FormSerialization">13.2.</a>&nbsp;
    表单(Form)序列化<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#JSONSerialization">13.3.</a>&nbsp;
    JSON 序列化<br>
    <a href="#StringOps">14.</a>&nbsp;
    字符操作<br>
    <a href="#ImplementationConsiderations">15.</a>&nbsp;
    实现时的考虑<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ServerMTI">15.1.</a>&nbsp;
    强制所有OpenID Providers需要实现的功能(Implement Features)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#DynamicMTI">15.2.</a>&nbsp;
    强制动态OpenID Providers需要实现的功能(Implement Features)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#DiscoReg">15.3.</a>&nbsp;
    发现(Discovery)与注册<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#RPMTI">15.4.</a>&nbsp;
    强制依赖方需要实现的功能<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ImplementationNotes">15.5.</a>&nbsp;
    实现时的注意事项<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#CodeNotes">15.5.1.</a>&nbsp;
    Authorization Code 实现注意事项<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#NonceNotes">15.5.2.</a>&nbsp;
    Nonce实现注意事项<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#FragmentNotes">15.5.3.</a>&nbsp;
    处理重定向 URI 时实现注意事项<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#CompatibilityNotes">15.6.</a>&nbsp;
    兼容注意事项<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#PreFinalIETFSpecs">15.6.1.</a>&nbsp;
    Pre-Final IETF Specifications<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#GoogleIss">15.6.2.</a>&nbsp;
    Google "iss" Value<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#RelatedSpecs">15.7.</a>&nbsp;
    相关的规范与实现指南<br>
    <a href="#Security">16.</a>&nbsp;
    安全性考虑<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#RequestDisclosure">16.1.</a>&nbsp;
    请求的公开(Disclosure)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ServerMasquerading">16.2.</a>&nbsp;
    服务端的伪造(Masquerading)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#TokenManufacture">16.3.</a>&nbsp;
    Token 生成/更新<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#AccessTokenDisclosure">16.4.</a>&nbsp;
    Access Token的公开(Disclosure)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ResponseDisclosure">16.5.</a>&nbsp;
    服务端响应的公开(Disclosure)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ServerResponseRepudiation">16.6.</a>&nbsp;
    服务端响应的认可性(Repudiation)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#RequestRepudation">16.7.</a>&nbsp;
    请求的认可性(Repudiation)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#AccessTokenRedirect">16.8.</a>&nbsp;
    Access Token 重定向<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#TokenReuse">16.9.</a>&nbsp;
    Token的重用<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#AuthCodeCapture">16.10.</a>&nbsp;
    窃听或泄漏 Authorization Codes (二次验证被拦截(Capture))<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#TokenSubstitution">16.11.</a>&nbsp;
    Token 被替换<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#TimingAttack">16.12.</a>&nbsp;
    定时(Timing)攻击<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#OtherCryptoAttacks">16.13.</a>&nbsp;
    其他密码(Crypto)相关攻击<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#SigningOrder">16.14.</a>&nbsp;
    签名与加密顺序<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#IssuerIdentifier">16.15.</a>&nbsp;
    Issuer的识别<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ImplicitFlowThreats">16.16.</a>&nbsp;
    Implicit流程的威胁<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#TLSRequirements">16.17.</a>&nbsp;
    TLS的必要性<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#TokenLifetime">16.18.</a>&nbsp;
    Access Tokens 与 Refresh Tokens的生命周期<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#SymmetricKeyEntropy">16.19.</a>&nbsp;
    对称密钥的无序(Entropy)<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#NeedForSignedRequests">16.20.</a>&nbsp;
    需要签名请求<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#NeedForEncryptedRequests">16.21.</a>&nbsp;
    需要加密请求<br>
    <a href="#Privacy">17.</a>&nbsp;
    隐私的考虑<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#PII">17.1.</a>&nbsp;
    个人身份信息<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#AccessMonitoring">17.2.</a>&nbsp;
    数据访问监控<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#Correlation">17.3.</a>&nbsp;
    相关性<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#OfflineAccessPrivacy">17.4.</a>&nbsp;
    离线访问<br>
    <a href="#IANA">18.</a>&nbsp;
    IANA 的考虑<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ClaimsRegistry">18.1.</a>&nbsp;
    JSON Web Token Claims 注册<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ClaimsContents">18.1.1.</a>&nbsp;
    注册(Registry)的内容<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#OAuthParametersRegistry">18.2.</a>&nbsp;
    OAuth 参数注册<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ParametersContents">18.2.1.</a>&nbsp;
    注册(Registry)的内容<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#OAuthErrorRegistry">18.3.</a>&nbsp;
    OAuth 扩展错误注册<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#ErrorContents">18.3.1.</a>&nbsp;
    注册(Registry)的内容<br>
    <a href="#rfc.references1">19.</a>&nbsp;
    引用<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#rfc.references1">19.1.</a>&nbsp;
    规范引用<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#rfc.references2">19.2.</a>&nbsp;
    资料引用<br>
    <a href="#AuthorizationExamples">附录&nbsp;A.</a>&nbsp;
    授权示例<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#codeExample">A.1.</a>&nbsp;
    使用 response_type=code 示例<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#id_tokenExample">A.2.</a>&nbsp;
    使用 response_type=id_token 示例<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a
        href="#id_token-tokenExample">A.3.</a>&nbsp;
    使用 response_type=id_token&nbsp;token 示例<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#code-id_tokenExample">A.4.</a>&nbsp;
    使用 response_type=code&nbsp;id_token 示例<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#code-tokenExample">A.5.</a>&nbsp;
    使用 response_type=code&nbsp;token 示例<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#code-id_token-tokenExample">A.6.</a>&nbsp;
    使用 response_type=code&nbsp;id_token&nbsp;token 示例<br>
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#ExampleRSAKey">A.7.</a>&nbsp;
    RSA 密钥使用示例<br>
    <a href="#Acknowledgements">附录&nbsp;B.</a>&nbsp;
    致谢<br>
    <a href="#Notices">附录&nbsp;C.</a>&nbsp;
    声明<br>
    <a href="#rfc.authors">§</a>&nbsp;
    作者地址<br>
</p>
<br clear="all">

<a name="Introduction"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.1"></a>

<h3>1.&nbsp;
    介绍</h3>

<p>
    OpenID Connect 1.0 是一个在OAuth 2.0之上的简单身份认证
    <a class="info" href="#RFC6749">[RFC6749]<span> (</span><span
            class="info">Hardt, D., “OAuth 2.0 授权框架,” 2012年10月.</span><span>)</span></a>
    协议. 它允许客户端(Client)在一个授权服务器(Authorization Server)上执行认证(authentication),
    并验证最终用户(End-User)的身份, 同时以互操作性和类似REST方式获取最终用户的基本配置信息.

</p>

<p>
    OpenID Connect Core 1.0 规范定义了核心的OpenID Connect功能:
    身份认证构建在OAuth 2.0之上并且使用Claims来传递最终用户(End-User)相关信息.
    它同时描述安全与隐私考虑使用OpenID Connect.

</p>

<p>
    在背后,
    <a class="info" href="#RFC6749">OAuth 2.0授权框架<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 授权框架,” 2012年10月.</span><span>)</span></a>
    [RFC6749]
    与 <a class="info" href="#RFC6750">OAuth 2.0 Bearer Token Usage<span> (</span><span
        class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” 2012年10月.</span><span>)</span></a>
    [RFC6750]
    规范为第三方应用程序获取与使用受保护的HTTP资源提供了一个通用的框架.
    他定义了获取与使用Access Token去访问资源的机制但却未定义提供身份信息的方式方法.
    值得注意的是, 在OAuth 2.0协议中, 没有提供关于认证最终用户(End-User)的相关信息.
    在本协议中将看到读者所期望的内容.

</p>

<p>
    OpenID Connect在OAuth 2.0授权流程的基础上,扩展实现了认证功能.
    在客户端(Clients)发起授权请求时扩展了请求的范围(scope)值包含<tt>openid</tt>.
    认证执行返回的信息是一个<a class="info" href="#JWT">JSON Web Token
    (JWT)<span> (</span><span
            class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” 2014年7月.</span><span>)</span></a>
    [JWT]
    名叫 ID Token (详见 <a class="info" href="#IDToken">第2节<span> (</span><span
        class="info">ID Token</span><span>)</span></a>).
    OAuth 2.0 认证服务端实现了 OpenID Connect 功能也被称作 OpenID 提供商 (OPs).
    OAuth 2.0 客户端(Clients) 使用 OpenID Connect 功能也被称作依赖方 (RPs).

</p>

<p>
    该规范假定依赖方(Relying Party)已经从OpenID提供商(Provider)获取了相关
    配置信息, 包括它的授权端点(Authorization Endpoint)与令牌端点(Token Endpoint)地址.
    这些信息通常是通过正常方式或其他机制获取的,
    详见 <a class="info" href="#OpenID.Discovery">OpenID
    Connect Discovery 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” 2014年11月.</span><span>)</span></a>
    [OpenID.Discovery]部分的描述.

</p>

<p>
    同样地, 该规范也假定依赖方(Relying Party)已经从OpenID提供商(Provider)获取了足够的凭证(sufficient credentials)
    且提供了必要的信息.
    这通常是通过动态注册(Dynamic Registration)或其他机制获取的,
    详见
    <a class="info" href="#OpenID.Registration">OpenID Connect
        Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” 2014年11月.</span><span>)</span></a>
    [OpenID.Registration]部分的描述.

</p>
<a name="rnc"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.1.1"></a>

<h3>1.1.&nbsp;
    必要的符号与约定</h3>

<p>关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 与 "OPTIONAL" 在该文档中已被定义,
    详见 <a class="info"
          href="#RFC2119">RFC
        2119<span> (</span><span class="info">Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” 1997年3月.</span><span>)</span></a>
    [RFC2119]部分.
</p>

<p>
    在该文档的 .txt 版本中, 当在协议的消息中使用这些值时,
    这些引用值仅被解释为字面意思,
    引号不能(MUST NOT)作为值的一部分.
    在该文档的 HTML 版本中,
    被解释为字面意思的值将用 <tt>固定宽度的字体</tt> 来表示.

</p>

<p>
    All uses of <a class="info" href="#JWS">JSON Web Signature (JWS)<span> (</span><span
        class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>
    [JWS]
    and <a class="info" href="#JWE">JSON Web Encryption (JWE)<span> (</span><span
        class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July&nbsp;2014.</span><span>)</span></a>
    [JWE]
    data structures in this specification utilize
    the JWS Compact Serialization or the JWE Compact Serialization;
    the JWS JSON Serialization and the JWE JSON Serialization are not used.

</p>
<a name="Terminology"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.1.2"></a>

<h3>1.2.&nbsp;
    术语</h3>

<p>
    该规范使用的措辞 "Access Token", "Authorization Code",
    "Authorization Endpoint", "Authorization Grant", "Authorization Server",
    "Client", "Client Authentication", "Client Identifier", "Client Secret",
    "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token",
    "Resource Owner", "Resource Server", "Response Type", 与 "Token Endpoint"
    被定义在 <a class="info" href="#RFC6749">OAuth
    2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749],
    措辞 "Claim Name", "Claim Value", "JSON Web Token (JWT)",
    "JWT Claims Set", 与 "Nested JWT"
    被定义在 <a class="info" href="#JWT">JSON Web Token
    (JWT)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>
    [JWT],
    措辞 "Header Parameter" 与 "JOSE Header"
    被定义在 <a class="info" href="#JWS">JSON Web Signature
    (JWS)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>
    [JWS],
    措辞 "User Agent" 被定义在 <a class="info"
                            href="#RFC2616">RFC
    2616<span> (</span><span class="info">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June&nbsp;1999.</span><span>)</span></a>
    [RFC2616],
    措辞 "Response Mode" 被定义在
    <a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
        Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>
    [OAuth.Responses].

</p>

<p>
    该规范也定义了以下措辞:
</p>
<blockquote class="text">
    <dl>
        <dt>Authentication</dt>
        <dd>

            Process used to achieve sufficient confidence in the binding
            between the Entity and the presented Identity.

        </dd>
        <dt>Authentication Request</dt>
        <dd>

            OAuth 2.0 Authorization Request using extension parameters and scopes
            defined by OpenID Connect to request that the End-User be authenticated
            by the Authorization Server, which is an OpenID Connect Provider,
            to the Client, which is an OpenID Connect Relying Party.

        </dd>
        <dt>Authentication Context</dt>
        <dd>

            Information that the Relying Party can require before it makes an
            entitlement decision with respect to an authentication response.
            Such context can include, but is not limited to, the actual
            authentication method used or level of assurance such as
            <a class="info" href="#ISO29115">ISO/IEC
                29115<span> (</span><span class="info">International Organization for Standardization, “ISO/IEC 29115:2013 -- 	  Information technology - Security techniques - Entity authentication 	  assurance framework,” March&nbsp;2013.</span><span>)</span></a>
            [ISO29115]
            entity authentication assurance level.

        </dd>
        <dt>Authentication Context Class</dt>
        <dd>

            Set of authentication methods or procedures that are considered
            to be equivalent to each other in a particular context.

        </dd>
        <dt>Authentication Context Class Reference</dt>
        <dd>

            Identifier for an Authentication Context Class.

        </dd>
        <dt>Authorization Code Flow</dt>
        <dd>

            OAuth 2.0 flow in which
            an Authorization Code is returned from the Authorization Endpoint and
            all tokens are returned from the Token Endpoint.

        </dd>
        <dt>Authorization Request</dt>
        <dd>

            OAuth 2.0 Authorization Request as defined by <a class="info"
                                                             href="#RFC6749">[RFC6749]<span> (</span><span
                class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>.

        </dd>
        <dt>Claim</dt>
        <dd>

            Piece of information asserted about an Entity.

        </dd>
        <dt>Claim Type</dt>
        <dd>

            Syntax used for representing a Claim Value.
            This specification defines Normal, Aggregated, and Distributed Claim Types.

        </dd>
        <dt>Claims Provider</dt>
        <dd>

            Server that can return Claims about an Entity.

        </dd>
        <dt>Credential</dt>
        <dd>

            Data presented as evidence of the right to use an identity
            or other resources.

        </dd>
        <dt>End-User</dt>
        <dd>

            Human participant.

        </dd>
        <dt>Entity</dt>
        <dd>

            Something that has a separate and distinct existence and that can be
            identified in a context. An End-User is one example of an Entity.

        </dd>
        <dt>Essential Claim</dt>
        <dd>

            Claim specified by the Client as being necessary to ensure a smooth
            authorization experience for the specific task requested by the End-User.

        </dd>
        <dt>Hybrid Flow</dt>
        <dd>

            OAuth 2.0 flow in which
            an Authorization Code is returned from the Authorization Endpoint,
            some tokens are returned from the Authorization Endpoint,
            and others are returned from the Token Endpoint.

        </dd>
        <dt>ID Token</dt>
        <dd>

            <a class="info" href="#JWT">JSON Web Token
                (JWT)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>
            [JWT] that contains Claims about the Authentication event.
            It MAY contain other Claims.

        </dd>
        <dt>Identifier</dt>
        <dd>

            Value that uniquely characterizes an Entity in a specific context.

        </dd>
        <dt>Identity</dt>
        <dd>

            Set of attributes related to an Entity.

        </dd>
        <dt>Implicit Flow</dt>
        <dd>

            OAuth 2.0 flow in which all tokens are returned from the Authorization Endpoint
            and neither the Token Endpoint nor an Authorization Code are used.

        </dd>
        <dt>Issuer</dt>
        <dd>

            Entity that issues a set of Claims.

        </dd>
        <dt>Issuer Identifier</dt>
        <dd>

            Verifiable Identifier for an Issuer.
            An Issuer Identifier is a case sensitive URL
            using the <tt>https</tt> scheme that
            contains scheme, host, and optionally, port number and path
            components and no query or fragment components.

        </dd>
        <dt>Message</dt>
        <dd>

            Request or a response between an OpenID
            Relying Party and an OpenID Provider.

        </dd>
        <dt>OpenID Provider (OP)</dt>
        <dd>

            OAuth 2.0 Authorization Server that is capable of
            Authenticating the End-User and
            providing Claims to a Relying Party
            about the Authentication event and the End-User.

        </dd>
        <dt>Request Object</dt>
        <dd>

            JWT that contains a set of request parameters as its Claims.

        </dd>
        <dt>Request URI</dt>
        <dd>

            URL that references a resource containing a Request Object.
            The Request URI contents MUST be retrievable by the
            Authorization Server.

        </dd>
        <dt>Pairwise Pseudonymous Identifier (PPID)</dt>
        <dd>

            Identifier that identifies the Entity to a Relying Party that cannot be correlated
            with the Entity's PPID at another Relying Party.

        </dd>
        <dt>Personally Identifiable Information (PII)</dt>
        <dd>

            Information that (a) can be used to identify the natural person
            to whom such information relates, or
            (b) is or might be directly or indirectly linked to a
            natural person to whom such information relates.

        </dd>
        <dt>Relying Party (RP)</dt>
        <dd>

            OAuth 2.0 Client application requiring End-User Authentication
            and Claims from an OpenID Provider.

        </dd>
        <dt>Sector Identifier</dt>
        <dd>

            Host component of a URL used by the Relying Party's organization
            that is an input to the computation of pairwise Subject Identifiers
            for that Relying Party.

        </dd>
        <dt>Self-Issued OpenID Provider</dt>
        <dd>

            Personal, self-hosted OpenID Provider that issues self-signed ID Tokens.

        </dd>
        <dt>Subject Identifier</dt>
        <dd>

            Locally unique and never
            reassigned identifier within the Issuer for the End-User,
            which is intended to be consumed by the Client.

        </dd>
        <dt>UserInfo Endpoint</dt>
        <dd>

            Protected Resource that, when presented with an Access Token by the Client,
            returns authorized information about the End-User represented by the corresponding
            Authorization Grant.
            The UserInfo Endpoint
            URL MUST use the <tt>https</tt> scheme and MAY contain
            port, path, and query parameter components.


        </dd>
        <dt>Validation</dt>
        <dd>

            Process intended to establish the soundness or correctness of a construct.

        </dd>
        <dt>Verification</dt>
        <dd>

            Process intended to test or prove the truth or accuracy of a fact or value.

        </dd>
        <dt>Voluntary Claim</dt>
        <dd>

            Claim specified by the Client as being useful but not Essential
            for the specific task requested by the End-User.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    对读者的重要提示: 本节中定义的术语是本规范不可分割的一部分,
    在实现时必须强制使用. 在该规范文本中的所有大写字母, 诸如
    "Issuer Identifier", 以及定义的相关措辞.
    不管读者在何时看到他们, 本节中的定义都必须遵循.

</p>

<p>
    若对这些术语的背景与使用想了解更多,请查看
    <a class="info" href="#RFC4949">Internet Security Glossary,
        Version 2<span> (</span><span
                class="info">Shirey, R., “Internet Security Glossary, Version 2,” August&nbsp;2007.</span><span>)</span></a>
    [RFC4949],
    <a class="info" href="#ISO29115">ISO/IEC 29115 Entity
        Authentication Assurance<span> (</span><span class="info">International Organization for Standardization, “ISO/IEC 29115:2013 -- 	  Information technology - Security techniques - Entity authentication 	  assurance framework,” March&nbsp;2013.</span><span>)</span></a>
    [ISO29115],
    与 <a class="info" href="#X.1252">ITU-T
    X.1252<span> (</span><span class="info">International Telecommunication Union, “ITU-T Recommendation X.1252 -- Cyberspace security -- Identity management 	  -- Baseline identity management terms and definitions,” November&nbsp;2010.</span><span>)</span></a>
    [X.1252].

</p>
<a name="Overview"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.1.3"></a>

<h3>1.3.&nbsp;
    概述</h3>

<p>OpenID Connect 协议可以抽象为以下几个步骤
</p>

<p>
</p>
<ol class="text">
    <li>RP (客户端) 发送请求给 OpenID 提供商 (OP).
    </li>
    <li>提供商(OP) 认证最终用户(End-User) 并获取授权.
    </li>
    <li>提供商(OP) 响应一个 ID Token 与一个 Access Token.
    </li>
    <li> RP 使用 Access Token 发送一个请求给 UserInfo Endpoint.
    </li>
    <li>UserInfo Endpoint 返回有关最终用户(End-User)的 Claims.
    </li>
</ol>
<p>

</p>

<p>
    这些步骤如下图所示:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request--------&gt;|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |&lt;--(2) AuthN &amp; AuthZ--&gt;|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |&lt;--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request-----&gt;|        |
|        |                                   |        |
|        |&lt;--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+
</pre>
</div>
<a name="IDToken"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.2"></a>

<h3>2.&nbsp;
    ID Token</h3>

<p>
    OpenID Connect的主要扩展是允许使用OAuth2.0的
    最终用户(End-Users)通过ID Token数据结构进行身份认证.
    ID Token是一个安全的令牌它包含客户端去授权服务器
    进行最终用户(End-User)的认证相关的Claims,
    和其他潜在的请求Claims.
    ID Token的具体表现为
    <a class="info" href="#JWT">JSON Web Token
        (JWT)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>
    [JWT].

</p>

<p>
    下列的Claims是用于ID Token中的包括在
    所有OAuth2.0流程中使用OpenID Connect:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>iss</dt>
        <dd>

            REQUIRED.
            Issuer Identifier for the Issuer of the response.
            The <tt>iss</tt> value is a case sensitive URL
            using the <tt>https</tt> scheme that
            contains scheme, host, and optionally, port number and path
            components and no query or fragment components.

        </dd>
        <dt>sub</dt>
        <dd>

            REQUIRED.
            Subject Identifier. A locally unique and never
            reassigned identifier within the Issuer for the End-User,
            which is intended to be consumed by the Client,
            e.g., <tt>24400320</tt>
            or <tt>AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4</tt>.
            It MUST NOT exceed 255 ASCII characters in length.
            The <tt>sub</tt> value is a case sensitive string.

        </dd>
        <dt>aud</dt>
        <dd>

            REQUIRED.
            Audience(s) that this ID Token is intended for.
            It MUST contain the OAuth 2.0 <tt>client_id</tt>
            of the Relying Party as an audience value.
            It MAY also contain identifiers for other audiences.
            In the general case,
            the <tt>aud</tt> value is an array of
            case sensitive strings.
            In the common special case when there is one audience,
            the <tt>aud</tt> value MAY be a single
            case sensitive string.

        </dd>
        <dt>exp</dt>
        <dd>

            REQUIRED.
            Expiration time on or after which the ID Token MUST NOT be
            accepted for processing. The processing of this parameter
            requires that the current date/time MUST be before the
            expiration date/time listed in the value. Implementers MAY
            provide for some small leeway, usually no more than a few
            minutes, to account for clock skew.
            Its value is a JSON number representing the number of seconds from
            1970-01-01T0:0:0Z as measured in UTC until the date/time.
            See <a class="info" href="#RFC3339">RFC
            3339<span> (</span><span class="info">Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July&nbsp;2002.</span><span>)</span></a>
            [RFC3339]
            for details regarding date/times in general and UTC in
            particular.

        </dd>
        <dt>iat</dt>
        <dd>

            REQUIRED.
            Time at which the JWT was issued.
            Its value is a JSON number representing the number of seconds from
            1970-01-01T0:0:0Z as measured in UTC until the date/time.

        </dd>
        <dt>auth_time</dt>
        <dd>

            Time when the End-User authentication occurred.
            Its value is a JSON number representing the number of seconds from
            1970-01-01T0:0:0Z as measured in UTC until the date/time.
            When a <tt>max_age</tt> request is made
            or when <tt>auth_time</tt> is requested
            as an Essential Claim,
            then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL.
            (The <tt>auth_time</tt> Claim semantically
            corresponds to the OpenID 2.0 <a class="info"
                                             href="#OpenID.PAPE">PAPE<span> (</span><span
                class="info">Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider 	  Authentication Policy Extension 1.0,” December&nbsp;2008.</span><span>)</span></a>
            [OpenID.PAPE]
            <tt>auth_time</tt> response parameter.)

        </dd>
        <dt>nonce</dt>
        <dd>

            String value used to associate a Client session
            with an ID Token, and to mitigate replay attacks.
            The value is passed through unmodified from the Authentication Request to the ID Token.
            If present in the ID Token,
            Clients MUST verify that
            the <tt>nonce</tt> Claim Value is equal to
            the value of the <tt>nonce</tt>
            parameter sent in the Authentication Request.
            If present in the Authentication Request, Authorization Servers
            MUST include a <tt>nonce</tt> Claim in the
            ID Token with the Claim Value
            being the nonce value sent in the Authentication Request.
            Authorization Servers SHOULD perform no other processing
            on <tt>nonce</tt> values used.
            The <tt>nonce</tt> value is a case sensitive string.

        </dd>
        <dt>acr</dt>
        <dd>

            OPTIONAL.
            Authentication Context Class Reference.
            String specifying an Authentication Context Class Reference value
            that identifies the Authentication Context Class that the
            authentication performed satisfied.
            The value "0" indicates the End-User authentication
            did not meet the requirements of
            <a class="info" href="#ISO29115">ISO/IEC
                29115<span> (</span><span class="info">International Organization for Standardization, “ISO/IEC 29115:2013 -- 	  Information technology - Security techniques - Entity authentication 	  assurance framework,” March&nbsp;2013.</span><span>)</span></a>
            [ISO29115] level 1.
            Authentication using a long-lived browser cookie, for instance, is one
            example where the use of "level 0" is appropriate. Authentications with
            level 0 SHOULD NOT be used to authorize access to any resource of any
            monetary value.
            (This corresponds to the OpenID 2.0
            <a class="info"
               href="#OpenID.PAPE">PAPE<span> (</span><span
                    class="info">Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider 	  Authentication Policy Extension 1.0,” December&nbsp;2008.</span><span>)</span></a>
            [OpenID.PAPE]
            <tt>nist_auth_level</tt> 0.)
            An absolute URI or an <a class="info" href="#RFC6711">RFC
            6711<span> (</span><span class="info">Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August&nbsp;2012.</span><span>)</span></a>
            [RFC6711]
            registered name
            SHOULD be used as the <tt>acr</tt> value;
            registered names MUST NOT be used with a different meaning than
            that which is registered.
            Parties using this claim will need to agree upon the meanings of
            the values used, which may be context-specific.
            The <tt>acr</tt> value is a case sensitive string.

        </dd>
        <dt>amr</dt>
        <dd>

            OPTIONAL.
            Authentication Methods References.
            JSON array of strings that are identifiers for authentication methods
            used in the authentication.
            For instance, values might indicate that both password and OTP
            authentication methods were used.
            The definition of particular values to be used in the
            <tt>amr</tt> Claim
            is beyond the scope of this specification.
            Parties using this claim will need to agree upon the meanings of
            the values used, which may be context-specific.
            The <tt>amr</tt> value is an array of
            case sensitive strings.

        </dd>
        <dt>azp</dt>
        <dd>

            OPTIONAL.
            Authorized party - the party to which the ID Token was issued.
            If present, it MUST contain the OAuth 2.0
            Client ID of this party.
            This Claim is only needed when
            the ID Token has a single audience value
            and that audience is different than the authorized party.
            It MAY be included even when the authorized party is the same
            as the sole audience.
            The <tt>azp</tt> value is a case sensitive string
            containing a StringOrURI value.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    ID Tokens 允许(MAY)包括其他的Claims.
    任何不被理解的Claims必须(MUST)被忽略.
    查看
    <a class="info" href="#CodeIDToken">3.1.3.6<span> (</span><span
            class="info">ID Token</span><span>)</span></a>,
    <a class="info"
       href="#HybridIDToken">3.3.2.11<span> (</span><span
            class="info">ID Token</span><span>)</span></a>,
    <a class="info" href="#StandardClaims">5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a>, 与
    <a class="info"
       href="#SelfIssuedResponse">7.4<span> (</span><span
            class="info">Self-Issued OpenID Provider Response</span><span>)</span></a>
    章节了解本规范中定义的其他Claims.

</p>

<p>
    ID Token必须(MUST)使用 <a class="info"
                          href="#JWS">JWS<span> (</span><span
        class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>
    [JWS] 进行签名与额外的方式进行相互签名
    且各自使用 <a class="info"
             href="#JWS">JWS<span> (</span><span
        class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>
    [JWS] 与 <a class="info" href="#JWE">JWE<span> (</span><span
        class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July&nbsp;2014.</span><span>)</span></a>
    [JWE] 进行加密, 从而提供认证, 完整性, 不可否认,
    与可选性, 保密性,
    详见 <a class="info"
          href="#SigningOrder">Section&nbsp;16.14<span> (</span><span
        class="info">Signing and Encryption Order</span><span>)</span></a>.
    如果 ID Token 是加密的, 它必须(MUST) 被签名然后加密,
    其结果是一个Nested JWT, 被称作 <a class="info"
                             href="#JWT">[JWT]<span> (</span><span
        class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>.
    ID Tokens MUST NOT use <tt>none</tt>
    as the <tt>alg</tt> value
    unless the Response Type used returns no ID Token from the
    Authorization Endpoint
    (such as when using the Authorization Code Flow)
    and the Client explicitly requested the use of
    <tt>none</tt> at Registration time.

</p>

<p>
    ID Tokens SHOULD NOT use the JWS or JWE
    <tt>x5u</tt>,
    <tt>x5c</tt>,
    <tt>jku</tt>, or
    <tt>jwk</tt>
    Header Parameter fields.
    Instead, references to keys used are
    communicated in advance using Discovery and Registration parameters,
    per <a class="info"
           href="#SigEnc">Section&nbsp;10<span> (</span><span
        class="info">Signatures and Encryption</span><span>)</span></a>.

</p>

<p>
    下列是一个非官方的在ID Token中的Claims(JWT Claims Set)示例:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "auth_time": 1311280969,
   "acr": "urn:mace:incommon:iap:silver"
  }
</pre>
</div>
<a name="Authentication"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3"></a>

<h3>3.&nbsp;
    认证</h3>

<p>
    OpenID Connect执行认证表现为最终用户的登录
    或判断最终用户已经登录.
    OpenID Connect返回的认证结果由服务端向客户端使用
    一种安全的机制执行的,这样客户端可以信赖它.
    因为这个原因, 客户端在这种情况下被称为依赖方(RP).

</p>

<p>
    认证的结果是返回一个
    ID Token, 详见 <a class="info" href="#IDToken">第2节<span> (</span><span
        class="info">ID Token</span><span>)</span></a>.
    它的Claims表达了诸如发行人(Issuer)的信息,
    对象标识()Subject Identifier), 当认证过期时 等等.

</p>

<p>
    认证包括下列的三种方式之一:
    授权码流程(Authorization Code Flow) (<tt>response_type=code</tt>),
    隐式流程(Implicit Flow) (<tt>response_type=id_token&nbsp;token</tt>
    或 <tt>response_type=id_token</tt>), 或
    混合流程(Hybrid Flow) (使用其他的在
    <a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
        Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>
    [OAuth.Responses] 中定义的响应类型).
    这些流程将决定ID Token与Access Token是如何返回给客户端的.

</p>

<p>
    这三类流程的特征总结在下面的非标准的表格中.
    该表格的目的是对具体的环境提供一些指导意见.

</p><br>
<hr class="insert">
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <colgroup>
        <col align="left">
        <col align="left">
        <col align="left">
        <col align="left">
    </colgroup>
    <tbody>
    <tr>
        <th align="left">属性</th>
        <th align="left">Authorization Code Flow</th>
        <th align="left">Implicit Flow</th>
        <th align="left">Hybrid Flow</th>
    </tr>
    <tr>
        <td align="left">从授权端点(Authorization Endpoint)返回所有令牌</td>
        <td align="left">no</td>
        <td align="left">yes</td>
        <td align="left">no</td>
    </tr>
    <tr>
        <td align="left">从令牌端点(Token Endpoint)返回所有令牌</td>
        <td align="left">yes</td>
        <td align="left">no</td>
        <td align="left">no</td>
    </tr>
    <tr>
        <td align="left">Tokens not revealed to User Agent</td>
        <td align="left">yes</td>
        <td align="left">no</td>
        <td align="left">no</td>
    </tr>
    <tr>
        <td align="left">Client can be authenticated</td>
        <td align="left">yes</td>
        <td align="left">no</td>
        <td align="left">yes</td>
    </tr>
    <tr>
        <td align="left">Refresh Token possible</td>
        <td align="left">yes</td>
        <td align="left">no</td>
        <td align="left">yes</td>
    </tr>
    <tr>
        <td align="left">Communication in one round trip</td>
        <td align="left">no</td>
        <td align="left">yes</td>
        <td align="left">no</td>
    </tr>
    <tr>
        <td align="left">Most communication server-to-server</td>
        <td align="left">yes</td>
        <td align="left">no</td>
        <td align="left">varies</td>
    </tr>
    </tbody>
</table>
<br clear="all">
<table border="0" cellpadding="0" cellspacing="2" align="center">
    <tbody>
    <tr>
        <td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;OpenID Connect 认证流程&nbsp;</b></font><br>
        </td>
    </tr>
    </tbody>
</table>
<hr class="insert">

<p>
    流程的使用是由认证请求时包含的 <tt>response_type</tt>
    值所决定的.
    这些流程中可选的 <tt>response_type</tt> 值如下:

</p><br>
<hr class="insert">
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <colgroup>
        <col align="left">
        <col align="left">
    </colgroup>
    <tbody>
    <tr>
        <th align="left">"response_type" 值</th>
        <th align="left">流程</th>
    </tr>
    <tr>
        <td align="left"><tt>code</tt>&nbsp;</td>
        <td align="left">Authorization Code Flow</td>
    </tr>
    <tr>
        <td align="left"><tt>id_token</tt>&nbsp;</td>
        <td align="left">Implicit Flow</td>
    </tr>
    <tr>
        <td align="left"><tt>id_token&nbsp;token</tt>&nbsp;</td>
        <td align="left">Implicit Flow</td>
    </tr>
    <tr>
        <td align="left"><tt>code&nbsp;id_token</tt>&nbsp;</td>
        <td align="left">Hybrid Flow</td>
    </tr>
    <tr>
        <td align="left"><tt>code&nbsp;token</tt>&nbsp;</td>
        <td align="left">Hybrid Flow</td>
    </tr>
    <tr>
        <td align="left"><tt>code&nbsp;id_token&nbsp;token</tt>&nbsp;</td>
        <td align="left">Hybrid Flow</td>
    </tr>
    </tbody>
</table>
<br clear="all">
<table border="0" cellpadding="0" cellspacing="2" align="center">
    <tbody>
    <tr>
        <td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;OpenID Connect "response_type"
            值&nbsp;</b></font><br>
        </td>
    </tr>
    </tbody>
</table>
<hr class="insert">

<p>
    <tt>code</tt> 响应类型值是在
    <a class="info" href="#RFC6749">OAuth
        2.0<span> (</span><span
                class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749]中定义,
    其他的响应类型值定义在
    <a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
        Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>
    [OAuth.Responses]
    规范中.
    注意: 在 OAuth 2.0 中为隐式流程(Implicit Flow)定义了
    <tt>token</tt> 响应类型,
    OpenID Connect 未使用它,
    因为没有 ID Token 将被退回.

</p>
<a name="CodeFlowAuth"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1"></a>

<h3>3.1.&nbsp;
    使用授权码(Authorization Code)认证流程</h3>

<p>
    本节将描述如何使用授权码(Authorization Code)流程进行认证.
    当使用授权码(Authorization Code)流程时,
    所有的令牌(token)从Token Endpoint获取并返回.

</p>

<p>
    授权码(Authorization Code)流程先给客户端返回一个授权码(Authorization Code),
    然后使用授权码直接去交换一个ID Token与Access Token.
    该流程的好处在于不会给用户代理(User Agent)暴露任何的令牌(tokens)
    与防止其他可能的恶意程序进入用户代理(User Agent).
    在使用授权码(Authorization Code)交换一个令牌(Access Token)之前,
    授权服务器(Authorization Server)能够认证客户端.
    授权码(Authorization Code)流程适用于客户端(Clients)能安全地在自己与
    授权服务器(Authorization Server)之间维护一个客户端密码(Client Secret).
</p>
<a name="CodeFlowSteps"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.1"></a>

<h3>3.1.1.&nbsp;
    授权码(Authorization Code)认证流程步骤</h3>

<p>
    授权码(Authorization Code)认证流程步骤如下.
</p>

<p>
</p>
<ol class="text">
    <li>
        客户端(Client)准备一个包括所需请求参数的认证请求(Authentication Request).
    </li>
    <li>
        客户端(Client)发送该请求给授权服务器(Authorization Server).
    </li>
    <li>
        授权服务器(Authorization Server)认证(Authenticates)最终用户(End-User).
    </li>
    <li>
        授权服务器(Authorization Server)获取最终用户(End-User)的同意/授权.
    </li>
    <li>
        授权服务器(Authorization Server)发送一个最终用户(End-User)的授权码(Authorization Code)给客户端(Client).
    </li>
    <li>
        客户端(Client)使用授权码(Authorization Code)向Token Endpoint发送请求并获取响应.
    </li>
    <li>
        客户端(Client)从响应的响应体中获取一个ID Token与Access Token.
    </li>
    <li>
        客户端(Client)校验ID令牌(ID token)并取回最终用户(End-User)的主体标识符(Subject Identifier).
    </li>
</ol>
<p>

</p>
<a name="AuthorizationEndpoint"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.2"></a>

<h3>3.1.2.&nbsp;
    授权端点(Authorization Endpoint)</h3>

<p>
    授权端点(Authorization Endpoint)执行对最终用户(End-User)的认证(Authentication).
    这是通过发送用户代理(User Agent)给授权服务器(Authorization Server)的
    授权端点(Authorization Endpoint)进行认证(Authentication)与授权(Authorization)完成的,
    这将使用OAuth 2.0协议中定义的请求参数,新增的参数以及OpenID Connect协议中定义的参数值.

</p>

<p>
    与授权端点(Authorization Endpoint)的通信必须(MUST)使用TLS连接.
    详见 <a class="info"
           href="#TLSRequirements">Section&nbsp;16.17<span> (</span><span
        class="info">TLS的必要性</span><span>)</span></a> 获取更多使用TLS的信息.

</p>
<a name="AuthRequest"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.2.1"></a>

<h3>3.1.2.1.&nbsp;
    认证请求</h3>

<p>
    一个认证请求(Authentication Request)是一个最终用户(End-User)
    被授权服务器(Authorization Server)进行认证的
    OAuth 2.0的授权请求(Authorization Request).

</p>

<p>
    授权服务器(Authorization Servers)必须(MUST)支持使用 HTTP定义的 <tt>GET</tt> 与
    <tt>POST</tt> 请求方式 <a class="info"
                                        href="#RFC2616">RFC
        2616<span> (</span><span class="info">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “超文本传输协议 -- HTTP/1.1,” June&nbsp;1999.</span><span>)</span></a>
    [RFC2616] 在授权端点(Authorization Endpoint).
    客户端(Clients)可以(MAY)使用HTTP的 <tt>GET</tt> 或
    <tt>POST</tt> 请求方式发送授权请求(Authorization Request)
    到授权服务器(Authorization Server). 如果使用 HTTP的
    <tt>GET</tt> 请求方式, 则请求参数使用
    查询字符(Query String)序列化, 参照 <a class="info"
                                           href="#QuerySerialization">Section&nbsp;13.1<span> (</span><span
            class="info">Query String Serialization</span><span>)</span></a> 进行序列化.
    如果使用 HTTP的 <tt>POST</tt>
    请求方式, 则请求参数使用
    表单(Form)序列化, 参照 <a class="info"
                               href="#FormSerialization">Section&nbsp;13.2<span> (</span><span
            class="info">Form Serialization</span><span>)</span></a> 进行序列化.
</p>

<p>
    在授权码(Authorization Code)流程中, OpenID Connect使用了OAuth 2.0协议中的请求参数如下:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>scope</dt>
        <dd>

            REQUIRED.
            OpenID Connect requests MUST contain the <tt>openid</tt> scope value.
            If the <tt>openid</tt> scope value is not present,
            the behavior is entirely unspecified.
            Other scope values MAY be present.
            Scope values used that are not understood by an implementation SHOULD be ignored.
            See Sections <a class="info"
                            href="#ScopeClaims">5.4<span> (</span><span
                class="info">Requesting Claims using Scope Values</span><span>)</span></a>
            and <a class="info"
                   href="#OfflineAccess">11<span> (</span><span
                class="info">Offline Access</span><span>)</span></a>
            for additional scope values defined by this specification.

        </dd>
        <dt>response_type</dt>
        <dd>

            REQUIRED.
            OAuth 2.0 Response Type value that determines
            the authorization processing flow to be used,
            including what parameters are returned from the endpoints used.
            When using the Authorization Code Flow, this value is
            <tt>code</tt>.

        </dd>
        <dt>client_id</dt>
        <dd>

            REQUIRED.
            OAuth 2.0 Client Identifier
            valid at the Authorization Server.

        </dd>
        <dt>redirect_uri</dt>
        <dd>

            REQUIRED.
            Redirection URI to which the response will be sent.
            This URI MUST exactly match one of the Redirection URI values
            for the Client pre-registered at the OpenID Provider,
            with the matching performed as described in
            Section 6.2.1 of <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span
                class="info">Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January&nbsp;2005.</span><span>)</span></a>
            (Simple String Comparison).
            When using this flow, the Redirection URI
            SHOULD use the <tt>https</tt> scheme;
            however, it MAY use the <tt>http</tt> scheme,
            provided that the Client Type is
            <tt>confidential</tt>,
            as defined in Section 2.1 of OAuth 2.0, and
            provided the OP allows the use of
            <tt>http</tt> Redirection URIs in this case.
            The Redirection URI MAY use an alternate scheme,
            such as one that is intended to identify a callback into a native application.

        </dd>
        <dt>state</dt>
        <dd>

            RECOMMENDED.
            Opaque value used
            to maintain state between the request and the callback.
            Typically, Cross-Site Request Forgery (CSRF, XSRF)
            mitigation is done by cryptographically binding the value of
            this parameter with a browser cookie.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    OpenID Connect也使用了OAuth2.0协议中定义在
    <a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
        Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>
    [OAuth.Responses] 中的以下请求参数:

</p>

<p>

</p>
<blockquote class="text">
    <dl>
        <dt>response_mode</dt>
        <dd>

            OPTIONAL.
            Informs the Authorization Server of the mechanism to be used
            for returning parameters from the Authorization Endpoint.
            This use of this parameter is NOT RECOMMENDED when the Response Mode
            that would be requested is the default mode specified for the Response Type.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    本协议也定义了以下的请求参数:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>nonce</dt>
        <dd>

            OPTIONAL.
            String value used to associate a Client session
            with an ID Token, and to mitigate replay attacks.
            The value is passed through unmodified from the Authentication Request to the ID Token.
            Sufficient entropy MUST be present in the
            <tt>nonce</tt> values used to prevent
            attackers from guessing values.
            For implementation notes, see <a class="info"
                                             href="#NonceNotes">Section&nbsp;15.5.2<span> (</span><span
                class="info">Nonce Implementation Notes</span><span>)</span></a>.

        </dd>
        <dt>display</dt>
        <dd>

            OPTIONAL.
            ASCII string value that specifies
            how the Authorization Server displays the authentication and
            consent user interface pages to the End-User.
            The defined values are:


            <blockquote class="text">
                <dl>
                    <dt>page</dt>
                    <dd>

                        The Authorization Server SHOULD display the
                        authentication and consent UI consistent with a full User Agent page
                        view. If the display parameter is not specified, this is the
                        default display mode.

                    </dd>
                    <dt>popup</dt>
                    <dd>

                        The Authorization Server SHOULD display the
                        authentication and consent UI consistent with a popup User Agent
                        window.
                        The popup User Agent window should be of an appropriate size
                        for a login-focused dialog and should not obscure
                        the entire window that it is popping up over.

                    </dd>
                    <dt>touch</dt>
                    <dd>

                        The Authorization Server SHOULD display the
                        authentication and consent UI consistent with a device that
                        leverages a touch interface.

                    </dd>
                    <dt>wap</dt>
                    <dd>

                        The Authorization Server SHOULD display the
                        authentication and consent UI consistent with a "feature phone"
                        type display.

                    </dd>
                </dl>
            </blockquote>

            The Authorization Server MAY also attempt to detect the capabilities
            of the User Agent and present an appropriate display.

        </dd>
        <dt>prompt</dt>
        <dd>

            OPTIONAL.
            Space delimited, case sensitive list of ASCII string values
            that specifies whether the Authorization Server prompts
            the End-User for reauthentication and consent.
            The defined values are:


            <blockquote class="text">
                <dl>
                    <dt>none</dt>
                    <dd>

                        The Authorization Server
                        MUST NOT display any authentication or consent
                        user interface pages.
                        An error is returned
                        if an End-User
                        is not already authenticated or the Client does not have
                        pre-configured consent for the requested
                        Claims or does not fulfill other conditions for processing the request.
                        The error code will typically be
                        <tt>login_required</tt>,
                        <tt>interaction_required</tt>,
                        or another code defined in <a class="info"
                                                      href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
                            class="info">Authentication Error Response</span><span>)</span></a>.
                        This can be used as a
                        method to check for existing authentication and/or consent.

                    </dd>
                    <dt>login</dt>
                    <dd>

                        The Authorization Server SHOULD prompt the
                        End-User for reauthentication.
                        If it cannot reauthenticate the End-User, it MUST return an error,
                        typically <tt>login_required</tt>.

                    </dd>
                    <dt>consent</dt>
                    <dd>

                        The Authorization Server SHOULD prompt the End-User for consent
                        before returning information to the Client.
                        If it cannot obtain consent, it MUST return an error,
                        typically <tt>consent_required</tt>.

                    </dd>
                    <dt>select_account</dt>
                    <dd>

                        The Authorization Server SHOULD
                        prompt the End-User to select a user account. This enables
                        an End-User who has multiple accounts at the Authorization Server
                        to select amongst the multiple accounts that they might have
                        current sessions for.
                        If it cannot obtain an account selection choice made by the End-User,
                        it MUST return an error,
                        typically <tt>account_selection_required</tt>.

                    </dd>
                </dl>
            </blockquote>

            The <tt>prompt</tt> parameter
            can be used by the Client to make sure that the End-User is
            still present for the current session or to bring attention to the
            request. If this parameter contains <tt>none</tt>
            with any other value, an
            error is returned.

        </dd>
        <dt>max_age</dt>
        <dd>

            OPTIONAL.
            Maximum Authentication Age.
            Specifies the allowable elapsed time in seconds
            since the last time the End-User was actively
            authenticated by the OP. If the elapsed time is greater than
            this value, the OP MUST attempt to actively
            re-authenticate the End-User.
            (The <tt>max_age</tt> request parameter corresponds to
            the OpenID 2.0 <a class="info"
                              href="#OpenID.PAPE">PAPE<span> (</span><span
                class="info">Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider 	  Authentication Policy Extension 1.0,” December&nbsp;2008.</span><span>)</span></a>
            [OpenID.PAPE]
            <tt>max_auth_age</tt> request parameter.)
            When <tt>max_age</tt> is used, the ID Token returned
            MUST include an <tt>auth_time</tt> Claim Value.

        </dd>
        <dt>ui_locales</dt>
        <dd>

            OPTIONAL.
            End-User's preferred languages and scripts for the user interface,
            represented as a space-separated list of
            <a class="info"
               href="#RFC5646">BCP47<span> (</span><span
                    class="info">Phillips, A. and M. Davis, “Tags for Identifying Languages,” September&nbsp;2009.</span><span>)</span></a>
            [RFC5646] language tag values,
            ordered by preference.
            For instance, the value "fr-CA fr en" represents a preference
            for French as spoken in Canada,
            then French (without a region designation),
            followed by English (without a region designation).
            An error SHOULD NOT result if some or all of the requested locales
            are not supported by the OpenID Provider.

        </dd>
        <dt>id_token_hint</dt>
        <dd>

            OPTIONAL.
            ID Token previously issued by the Authorization Server
            being passed as a hint about the End-User's current or past
            authenticated session with the Client.
            If the End-User identified by the ID Token is logged in or is logged in by the request,
            then the Authorization Server returns a positive response;
            otherwise, it SHOULD return
            an error, such as <tt>login_required</tt>.
            When possible, an <tt>id_token_hint</tt>
            SHOULD be present when <tt>prompt=none</tt> is used
            and an <tt>invalid_request</tt> error
            MAY be returned if it is not;
            however, the server SHOULD respond successfully when possible,
            even if it is not present.
            The Authorization Server need not be listed as an
            audience of the ID Token when it is used as an
            <tt>id_token_hint</tt> value.

        </dd>
        <dt></dt>
        <dd>
            If the ID Token received by the RP from the OP is encrypted,
            to use it as an <tt>id_token_hint</tt>, the Client MUST
            decrypt the signed ID Token contained within the encrypted ID Token.
            The Client MAY re-encrypt the signed ID token to the Authentication Server
            using a key that enables the server to decrypt the ID Token,
            and use the re-encrypted ID token as the
            <tt>id_token_hint</tt> value.

        </dd>
        <dt>login_hint</dt>
        <dd>

            OPTIONAL.
            Hint to the Authorization Server
            about the login identifier the End-User might use to log in (if necessary).
            This hint can be used by an RP if it first asks the End-User for their e-mail
            address (or other identifier) and then wants to pass that value as a hint
            to the discovered authorization service.
            It is RECOMMENDED that the hint value match the value used for discovery.
            This value MAY also be a phone number in the format specified for the
            <tt>phone_number</tt> Claim.
            The use of this parameter is left to the OP's discretion.

        </dd>
        <dt>acr_values</dt>
        <dd>

            OPTIONAL.
            Requested Authentication Context Class Reference values.
            Space-separated string that specifies the <tt>acr</tt>
            values that the Authorization Server is being requested to use
            for processing this Authentication Request,
            with the values appearing in order of preference.
            The Authentication Context Class satisfied by the authentication
            performed is returned as the <tt>acr</tt> Claim Value,
            as specified in <a class="info" href="#IDToken">Section&nbsp;2<span> (</span><span
                class="info">ID Token</span><span>)</span></a>.
            The <tt>acr</tt> Claim is requested as
            a Voluntary Claim by this parameter.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    其他的一些参数也可能(MAY)被发送.
    详见以下章节 <a class="info"
                    href="#ImplicitAuthorizationEndpoint">3.2.2<span> (</span><span
        class="info">Authorization Endpoint</span><span>)</span></a>,
    <a class="info" href="#HybridAuthorizationEndpoint">3.3.2<span> (</span><span
            class="info">Authorization Endpoint</span><span>)</span></a>,
    <a class="info"
       href="#ClaimsLanguagesAndScripts">5.2<span> (</span><span
            class="info">Claims Languages and Scripts</span><span>)</span></a>,
    <a class="info" href="#ClaimsParameter">5.5<span> (</span><span
            class="info">Requesting Claims using the "claims" Request Parameter</span><span>)</span></a>,
    <a class="info" href="#JWTRequests">6<span> (</span><span
            class="info">Passing Request Parameters as JWTs</span><span>)</span></a>, 与
    <a class="info"
       href="#RegistrationParameter">7.2.1<span> (</span><span
            class="info">Providing Information with the "registration" Request Parameter</span><span>)</span></a>
    获取更多在本协议中定义的可用于授权请求(Authorization Request)时的参数与参数值.

</p>

<p>
    下面是一个使用HTTP 302重定向响应到
    客户端(Client)的非规范性(non-normative)的示例,
    这将在用户代理(User Agent)发送一个认证请求(Authentication Request)
    到授权端点(Authorization Endpoint)时触发
    (仅为了更好的显示使用了换行):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 302 Found
  Location: https://server.example.com/authorize?
    response_type=code
    &amp;scope=openid%20profile%20email
    &amp;client_id=s6BhdRkqt3
    &amp;state=af0ifjsldkj
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
</pre>
</div>
<p>
    下面是一个非规范性(non-normative)的请求示例,
    在授权服务器(Authorization Server)响应HTTP 302重定向响应给客户端(Client)之前
    用户代理(User Agent)发送的请求
    (仅为了更好的显示使用了换行):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /authorize?
    response_type=code
    &amp;scope=openid%20profile%20email
    &amp;client_id=s6BhdRkqt3
    &amp;state=af0ifjsldkj
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
  Host: server.example.com
</pre>
</div>
<a name="AuthRequestValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.2.2"></a>

<h3>3.1.2.2.&nbsp;
    认证请求的验证</h3>

<p>
    授权服务器(Authorization Server)必须(MUST)验证收到的请求,如下所示:

</p>

<p>
</p>
<ol class="text">
    <li>
        授权服务器(Authorization Server)必须(MUST)验证所有OAuth2.0规范中的参数.

    </li>
    <li>
        验证当前请求中的 <tt>scope</tt> 参数和
        包含 <tt>openid</tt> 的scope值.
        (如果当前没有 <tt>openid</tt> scope值,
        该请求也应该是一个OAuth2.0的请求,
        但不是一个OpenID Connect请求.)

    </li>
    <li>
        授权服务器(Authorization Server)必须(MUST)验证请求中所有必要(REQUIRED)的参数
        并要符合本规范的使用.

    </li>
    <li>
        If the <tt>sub</tt> (subject) Claim
        is requested with a specific value for the ID Token,
        the Authorization Server MUST only send a positive response
        if the End-User identified by that <tt>sub</tt> value
        has an active session with the Authorization Server
        or has been Authenticated as a result of the request.
        The Authorization Server MUST NOT reply with an ID Token or
        Access Token for a different user,
        even if they have an active session with the Authorization Server.
        Such a request can be made either using an
        <tt>id_token_hint</tt> parameter
        or by requesting a specific Claim Value
        as described in <a class="info"
                           href="#IndividualClaimsRequests">Section&nbsp;5.5.1<span> (</span><span
            class="info">Individual Claims Requests</span><span>)</span></a>,
        if the <tt>claims</tt> parameter
        is supported by the implementation.

    </li>
</ol>
<p>

</p>

<p>
    在 <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
        class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749] 协议中规定,
    授权服务器(Authorization Servers)应该(SHOULD)忽略无法识别的请求参数.

</p>

<p>
    如果授权服务器(Authorization Server)遇到任何的错误(error),
    它必须(MUST)返回一个错误(error)的响应, 详见 <a class="info"
                                             href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
        class="info">Authentication Error Response</span><span>)</span></a>.

</p>
<a name="Authenticates"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.2.3"></a>

<h3>3.1.2.3.&nbsp;
    授权服务器认证最终用户(End-User)</h3>

<p>
    若请求是有效的, 则授权服务器(Authorization Server)将根据请求所包括的参数值尝试
    验证最终用户(End-User)或决定最终用户(End-User)是否是已验证的.
    至于授权服务器(Authorization Server)采用什么方式来认证最终用户(如账号与密码, session cookies 等)
    已经超出本协议规范的范围.
    根据使用的请求参数值与使用的认证方式, 一个验证用户接口(interface)
    也许(MAY)被授权服务器(Authorization Server)对外开放.

</p>

<p>
    在下列情况中,授权服务器(Authorization Server)必须(MUST)对
    最终用户进行认证:
</p>
<ul class="text">
    <li>
        尚未进行认证的最终用户(End-User).
    </li>
    <li>
        认证请求(Authentication Request)中包含 <tt>prompt</tt> 参数并且值为
        <tt>login</tt>. 在这种情况下,
        授权服务器(Authorization Server)必须(MUST)重新认证(reauthenticate)
        最终用户(End-User)即使最终用户已经被认证过.
    </li>
</ul>
<p>

</p>

<p>
    在下列情况中,授权服务器(Authorization Server)必须不能(MUST NOT)与
    最终用户(End-User)进行交互(interact):
</p>
<ul class="text">
    <li>
        认证请求(Authentication Request)中包含 <tt>prompt</tt> 参数并且值为
        <tt>none</tt>. 在这种情况下,
        如果一个最终用户(End-User)还没被验证或没有使用静默方式(silently)认证,
        则授权服务器(Authorization Server)必须(MUST)返回一个错误(error).
    </li>
</ul>
<p>

</p>

<p>
    当与最终用户(End-User)进行交互(interacting)时,
    授权服务器(Authorization Server)必须(MUST)对
    跨站伪造请求(Cross-Site Request Forgery)与点击劫持(Clickjacking)采取适当的措施,
    关于这部分的描述请参考 <a class="info" href="#RFC6749">OAuth
    2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749] 中10.12 与 10.13 章节.

</p>
<a name="Consent"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.2.4"></a>

<h3>3.1.2.4.&nbsp;
    授权服务器获取最终用户(End-User)同意/授权</h3>

<p>
    一旦最终用户(End-User)通过认证, 授权服务器必须(MUST)在给
    信任方(Relying Party)响应(releasing)信息前获取一个最终用户授权决定.
    当允许的请求参数使用时,
    或许(MAY)是通过一个与最终用户的交互式对话(interactive dialogue),
    使它明确什么是同意或通过建立同意,通过条件处理的请求
    或其他方式(如通过之前的管理(administrative)同意).
    章节 <a class="info" href="#IDToken">2<span> (</span><span
        class="info">ID Token</span><span>)</span></a> 和
    <a class="info" href="#UserInfo">5.3<span> (</span><span
            class="info">UserInfo Endpoint</span><span>)</span></a> 描述相关信息机制.

</p>
<a name="AuthResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.2.5"></a>

<h3>3.1.2.5.&nbsp;
    成功的认证响应</h3>

<p>
    一个认证响应(An Authentication Response)是一个OAuth2.0的授权响应信息,
    是从OP的授权端点(Authorization Endpoint)响应并返回从RP发送的
    授权请求(Authorization Request)消息.
</p>

<p>
    在使用授权码流程时, 认证响应必须(MUST)返回的参数是定义在
    <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749]
    协议4.1.2章节中的并在授权请求时通过<tt>redirect_uri</tt> 指定添加的查询参数
    且使用 <tt>application/x-www-form-urlencoded</tt>格式,
    除非指定了其他的响应模式(Response Mode).

</p>

<p>
    下面是一个非规范性(non-normative)的,
    在该流程中成功响应的示例(仅为了更好的显示使用了换行):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=SplxlOBeZQQYbYS6WxSbIA
    &amp;state=af0ifjsldkj
</pre>
</div>
<p>
    有关授权码实现的注意事项内容,请参考 <a class="info" href="#CodeNotes">15.5.1 章节<span> (</span><span
        class="info">Authorization Code Implementation Notes</span><span>)</span></a>.

</p>
<a name="AuthError"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.2.6"></a>

<h3>3.1.2.6.&nbsp;
    错误的认证响应</h3>

<p>
    一个错误的认证响应是一个OAuth2.0 错误授权响应信息反馈,
    该响应是从OP的授权端点(Authorization Endpoint)到RP发起的授权请求(Authorization Request)信息

</p>

<p>
    如果最终用户拒绝了请求或最终用户认证失败,
    OP(授权服务器)将使用定义在
    <a class="info" href="#RFC6749">OAuth
    2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749] 4.1.2.1章节
    中的错误响应(Error Response)参数通知RP(客户端).
    (HTTP错误与RFC 6749无关的将使用合适的HTTP状态码返回给用户代理(User Agent).)

</p>

<p>
    除非重定向URI(Redirection URI)是无效的,
    否则授权服务器(Authorization Server)将使用在授权请求(Authorization Request)中指定的重定向URI返回给客户端,
    包括适当的错误与状态参数.
    其他的参数可以不用(SHOULD NOT)返回.

</p>

<p>
    除了定义在OAuth2.0协议4.1.2.1章节中的错误码以外,
    本协议额外定义了以下错误码:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>interaction_required</dt>
        <dd>

            The Authorization Server
            requires End-User interaction of some form to proceed.
            This error MAY be returned when the
            <tt>prompt</tt> parameter value in the
            Authentication Request is <tt>none</tt>,
            but the Authentication Request cannot be completed
            without displaying a user interface for End-User interaction.

        </dd>
        <dt>login_required</dt>
        <dd>

            The Authorization Server requires
            End-User authentication. This error MAY be returned when the
            <tt>prompt</tt> parameter value in the
            Authentication Request is <tt>none</tt>,
            but the Authentication Request cannot be completed
            without displaying a user interface for End-User authentication.

        </dd>
        <dt>account_selection_required</dt>
        <dd>

            The End-User is REQUIRED
            to select a session at the Authorization Server. The End-User MAY
            be authenticated at the Authorization Server with different
            associated accounts, but the End-User did not select a session.
            This error MAY be returned
            when the <tt>prompt</tt> parameter value in the
            Authentication Request is <tt>none</tt>,
            but the Authentication Request cannot be completed
            without displaying a user interface to prompt for a session to use.

        </dd>
        <dt>consent_required</dt>
        <dd>

            The Authorization Server
            requires End-User consent. This error MAY be returned when the
            <tt>prompt</tt> parameter value in the
            Authentication Request is <tt>none</tt>,
            but the Authentication Request cannot be completed
            without displaying a user interface for End-User consent.

        </dd>
        <dt>invalid_request_uri</dt>
        <dd>

            The
            <tt>request_uri</tt> in
            the Authorization Request returns an error or contains invalid data.

        </dd>
        <dt>invalid_request_object</dt>
        <dd>

            The
            <tt>request</tt> parameter contains an invalid
            Request Object.

        </dd>
        <dt>request_not_supported</dt>
        <dd>

            OP不支持使用定义在
            <a class="info" href="#JWTRequests">章节&nbsp;6<span> (</span><span
                class="info">Passing Request Parameters as JWTs</span><span>)</span></a>
            中的 <tt>request</tt> 参数
        </dd>
        <dt>request_uri_not_supported</dt>
        <dd>
            OP不支持使用定义在
            <a class="info" href="#JWTRequests">章节&nbsp;6<span> (</span><span
                class="info">Passing Request Parameters as JWTs</span><span>)</span></a>
            中的 <tt>request_uri</tt> 参数
        </dd>
        <dt>registration_not_supported</dt>
        <dd>
            OP不支持使用定义在
             <a class="info"
                          href="#RegistrationParameter">章节&nbsp;7.2.1<span> (</span><span
                class="info">Providing Information with the "registration" Request Parameter</span><span>)</span></a>.
            中的 <tt>registration</tt> 参数
        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    错误(error)响应参数如下:

</p>
<blockquote class="text">
    <dl>
        <dt>error</dt>
        <dd>

            必须的(REQUIRED). 错误码.

        </dd>
        <dt>error_description</dt>
        <dd>

            可选的(OPTIONAL). 人类可读的使用ASCII编码的
            对错误的文字描述信息

        </dd>
        <dt>error_uri</dt>
        <dd>

            可选的(OPTIONAL). 一个包含关于错误的
            更多额外信息的万维网URI页面.

        </dd>
        <dt>state</dt>
        <dd>

            OAuth 2.0 状态值.
            如果授权请求包含参数<tt>state</tt>则是必须的(REQUIRED).
            设置从客户端收到的值.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    当使用授权码流程(Authorization Code Flow)时,
    除非指定了一个不同的响应模式(Response Mode),
    否则错误响应参数将添加为重定向URI(Redirection URI)的查询组件.

</p>

<p>

</p>

<p>
    下面是一个非规范性(non-normative)的, 在该流程中错误响应时的示例(换行为了更好的显示使用):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    error=invalid_request
    &amp;error_description=
      Unsupported%20response_type%20value
    &amp;state=af0ifjsldkj
</pre>
</div>


<a name="AuthResponseValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.2.7"></a>

<h3>3.1.2.7.&nbsp;
    认证响应的验证</h3>

<p>
    当使用授权码流程(Authorization Code Flow)时,
    客户端必须根据RFC 6749协议验证响应,
    特别是4.1.2章节与10.12章节中的内容.

</p>
<a name="TokenEndpoint"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.3"></a>

<h3>3.1.3.&nbsp;
    Token Endpoint</h3>

<p>
    To obtain an Access Token, an ID Token, and optionally a Refresh Token,
    the RP (Client) sends a Token Request to the Token Endpoint
    to obtain a Token Response, as described in
    Section 3.2 of <a class="info" href="#RFC6749">OAuth
    2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749],
    when using the Authorization Code Flow.

</p>

<p>
    Communication with the Token Endpoint MUST utilize TLS.
    See <a class="info"
           href="#TLSRequirements">Section&nbsp;16.17<span> (</span><span
        class="info">TLS Requirements</span><span>)</span></a> for more information on using TLS.

</p>
<a name="TokenRequest"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.3.1"></a>

<h3>3.1.3.1.&nbsp;
    Token Request</h3>

<p>
    A Client makes a Token Request by
    presenting its Authorization Grant (in the form of
    an Authorization Code) to the Token Endpoint
    using the <tt>grant_type</tt> value
    <tt>authorization_code</tt>, as described in
    Section 4.1.3 of <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
        class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749].
    If the Client is a Confidential Client, then it MUST
    authenticate to the Token Endpoint using the authentication method
    registered for its <tt>client_id</tt>,
    as described in <a class="info" href="#ClientAuthentication">Section&nbsp;9<span> (</span><span
        class="info">Client Authentication</span><span>)</span></a>.

</p>

<p>
    The Client sends the parameters to the Token Endpoint
    using the HTTP <tt>POST</tt> method and the
    Form Serialization, per <a class="info"
                               href="#FormSerialization">Section&nbsp;13.2<span> (</span><span
        class="info">Form Serialization</span><span>)</span></a>,
    as described in Section 4.1.3 of
    <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749].

</p>

<p>
    The following is a non-normative example of a Token Request
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

  grant_type=authorization_code&amp;code=SplxlOBeZQQYbYS6WxSbIA
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
</pre>
</div>
<a name="TokenRequestValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.3.2"></a>

<h3>3.1.3.2.&nbsp;
    Token Request Validation</h3>

<p>
    The Authorization Server MUST validate the Token Request as follows:

</p>

<p>
</p>
<ul class="text">
    <li>
        Authenticate the Client if it was issued Client Credentials
        or if it uses another Client Authentication method,
        per <a class="info" href="#ClientAuthentication">Section&nbsp;9<span> (</span><span
            class="info">Client Authentication</span><span>)</span></a>.

    </li>
    <li>
        Ensure the
        Authorization Code was issued to the authenticated Client.

    </li>
    <li>
        Verify that the Authorization Code is valid.

    </li>
    <li>
        If possible,
        verify that the Authorization Code has not been previously used.

    </li>
    <li>
        Ensure that the
        <tt>redirect_uri</tt> parameter value
        is identical to the <tt>redirect_uri</tt>
        parameter value that was included in the initial Authorization Request.
        If the <tt>redirect_uri</tt> parameter value
        is not present when there is only one registered
        <tt>redirect_uri</tt> value,
        the Authorization Server MAY return an error
        (since the Client should have included the parameter)
        or MAY proceed without an error
        (since OAuth 2.0 permits the parameter to be omitted in this case).

    </li>
    <li>
        Verify that the Authorization Code used was issued
        in response to an OpenID Connect Authentication Request
        (so that an ID Token will be returned from the Token Endpoint).

    </li>
</ul>
<p>

</p>
<a name="TokenResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.3.3"></a>

<h3>3.1.3.3.&nbsp;
    Successful Token Response</h3>

<p>
    After receiving and validating a valid and authorized Token Request
    from the Client, the Authorization Server returns a successful
    response that includes an ID Token and an Access Token. The
    parameters in the successful response are defined in Section 4.1.4
    of <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
        class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749].
    The response uses the <tt>application/json</tt>
    media type.

</p>

<p>
    The OAuth 2.0 <tt>token_type</tt> response parameter
    value MUST be <tt>Bearer</tt>,
    as specified in <a class="info" href="#RFC6750">OAuth 2.0 Bearer
    Token Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6750],
    unless another Token Type has been negotiated with the Client.
    Servers SHOULD support the <tt>Bearer</tt> Token Type;
    use of other Token Types is outside the scope of this specification.

</p>

<p>
    In addition to the response parameters specified by OAuth 2.0, the following
    parameters MUST be included in the response:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>id_token</dt>
        <dd>

            ID Token value associated with the
            authenticated session.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    All Token Responses that contain tokens, secrets, or other
    sensitive information MUST include the following HTTP response header
    fields and values:

</p><br>
<hr class="insert">
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <colgroup>
        <col align="left">
        <col align="left">
    </colgroup>
    <tbody>
    <tr>
        <th align="left">Header Name</th>
        <th align="left">Header Value</th>
    </tr>
    <tr>
        <td align="left">Cache-Control</td>
        <td align="left">no-store</td>
    </tr>
    <tr>
        <td align="left">Pragma</td>
        <td align="left">no-cache</td>
    </tr>
    </tbody>
</table>
<br clear="all">
<table border="0" cellpadding="0" cellspacing="2" align="center">
    <tbody>
    <tr>
        <td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;HTTP Response Headers and
            Values&nbsp;</b></font><br></td>
    </tr>
    </tbody>
</table>
<hr class="insert">

<p>
    The following is a non-normative example of a successful Token Response.
    The ID Token signature in the example can be verified with the key at
    <a class="info"
       href="#ExampleRSAKey">Appendix&nbsp;A.7<span> (</span><span
            class="info">RSA Key Used in Examples</span><span>)</span></a>.

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache

  {
   "access_token": "SlAV32hkKG",
   "token_type": "Bearer",
   "refresh_token": "8xLOxBtZp8",
   "expires_in": 3600,
   "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
     yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
     NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
     fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
     AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
     Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
     NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
     QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
     K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
     XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
  }
</pre>
</div>
<p>As specified in <a class="info" href="#RFC6749">OAuth
    2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749], Clients
    SHOULD ignore unrecognized response parameters.
</p>
<a name="TokenErrorResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.3.4"></a>

<h3>3.1.3.4.&nbsp;
    Token Error Response</h3>

<p>
    If the Token Request is invalid or unauthorized, the
    Authorization Server constructs the error response. The parameters
    of the Token Error Response are defined as in Section 5.2 of <a class="info"
                                                                    href="#RFC6749">OAuth
    2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749].
    The HTTP response body uses the <tt>application/json</tt>
    media type with HTTP response code of 400.

</p>

<p>The following is a non-normative example Token Error Response:
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 400 Bad Request
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache

  {
   "error": "invalid_request"
  }
</pre>
</div>
<a name="TokenResponseValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.3.5"></a>

<h3>3.1.3.5.&nbsp;
    Token Response Validation</h3>

<p>
    The Client MUST validate the Token Response as follows:
</p>
<ol class="text">
    <li>
        Follow the validation rules in RFC 6749,
        especially those in Sections 5.1 and 10.12.

    </li>
    <li>
        Follow the ID Token validation rules in <a class="info"
                                                   href="#IDTokenValidation">Section&nbsp;3.1.3.7<span> (</span><span
            class="info">ID Token Validation</span><span>)</span></a>.

    </li>
    <li>
        Follow the Access Token validation rules in <a class="info"
                                                       href="#CodeFlowTokenValidation">Section&nbsp;3.1.3.8<span> (</span><span
            class="info">Access Token Validation</span><span>)</span></a>.

    </li>
</ol>
<p>

</p>
<a name="CodeIDToken"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.3.6"></a>

<h3>3.1.3.6.&nbsp;
    ID Token</h3>

<p>
    The contents of the ID Token are as described in <a class="info"
                                                        href="#IDToken">Section&nbsp;2<span> (</span><span
        class="info">ID Token</span><span>)</span></a>.
    When using the Authorization Code Flow,
    these additional requirements for the following ID Token Claims apply:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>at_hash</dt>
        <dd>

            OPTIONAL.
            Access Token hash value.
            Its value is the base64url encoding of the left-most half of the
            hash of the octets of the ASCII representation of the
            <tt>access_token</tt> value,
            where the hash algorithm used is the hash algorithm
            used in the <tt>alg</tt> Header Parameter
            of the ID Token's JOSE Header.
            For instance, if the <tt>alg</tt> is
            <tt>RS256</tt>, hash the
            <tt>access_token</tt> value
            with SHA-256, then take the left-most 128 bits and base64url encode them.
            The <tt>at_hash</tt> value is a case sensitive string.

        </dd>
    </dl>
</blockquote>
<p>

</p>
<a name="IDTokenValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.3.7"></a>

<h3>3.1.3.7.&nbsp;
    ID Token Validation</h3>

<p>
    Clients MUST validate the ID Token in the Token Response
    in the following manner:

</p>

<p>
</p>
<ol class="text">
    <li>
        If the ID Token is encrypted, decrypt it using the
        keys and algorithms that the Client specified during Registration
        that the OP was to use to encrypt the ID Token.
        If encryption was negotiated with the OP at Registration time
        and the ID Token is not encrypted, the RP SHOULD reject it.

    </li>
    <li>
        The Issuer Identifier for the OpenID Provider
        (which is typically obtained during Discovery)
        MUST exactly match the value of the
        <tt>iss</tt> (issuer) Claim.

    </li>
    <li>
        The Client MUST validate that the
        <tt>aud</tt> (audience) Claim
        contains its <tt>client_id</tt> value
        registered at the Issuer identified by the
        <tt>iss</tt> (issuer) Claim
        as an audience.
        The <tt>aud</tt> (audience) Claim
        MAY contain an array with more than one element.
        The ID Token MUST be rejected if the ID Token does not list
        the Client as a valid audience, or if it contains additional audiences not trusted by the Client.

    </li>
    <li>
        If the ID Token contains multiple audiences, the Client SHOULD verify
        that an <tt>azp</tt> Claim is present.

    </li>
    <li>
        If an <tt>azp</tt> (authorized party) Claim is present,
        the Client SHOULD verify that its <tt>client_id</tt>
        is the Claim Value.

    </li>
    <li>
        If the ID Token is received via direct
        communication between the Client and the Token Endpoint
        (which it is in this flow), the TLS server
        validation MAY be used to validate the issuer in place of
        checking the token signature.
        The Client MUST validate the signature of all other ID Tokens according to
        <a class="info" href="#JWS">JWS<span> (</span><span
                class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>
        [JWS] using the algorithm specified in the
        JWT <tt>alg</tt> Header Parameter.
        The Client MUST use the keys provided by the Issuer.

    </li>
    <li>The <tt>alg</tt> value SHOULD be the default of
        <tt>RS256</tt>
        or the algorithm sent by the Client
        in the <tt>id_token_signed_response_alg</tt> parameter
        during Registration.
    </li>
    <li>If the JWT <tt>alg</tt> Header Parameter
        uses a MAC based algorithm such as
        <tt>HS256</tt>, <tt>HS384</tt>,
        or <tt>HS512</tt>,
        the octets of the UTF-8 representation of
        the <tt>client_secret</tt> corresponding to the
        <tt>client_id</tt> contained in the
        <tt>aud</tt> (audience) Claim are used as the key
        to validate the signature.
        For MAC based algorithms, the behavior is unspecified
        if the <tt>aud</tt> is multi-valued or
        if an <tt>azp</tt> value is present
        that is different than the <tt>aud</tt> value.

    </li>
    <li>
        The current time MUST be before the time represented by the
        <tt>exp</tt> Claim.

    </li>
    <li>The <tt>iat</tt> Claim can be used to reject tokens that
        were issued too far away from the current time, limiting the amount of
        time that nonces need to be stored to prevent attacks.
        The acceptable range is Client specific.
    </li>
    <li>
        If a nonce value was sent in the Authentication Request,
        a <tt>nonce</tt> Claim MUST be present
        and its value checked to verify that
        it is the same value as the one that was sent in the Authentication Request.
        The Client SHOULD check the <tt>nonce</tt> value
        for replay attacks.
        The precise method for detecting replay attacks is Client specific.

    </li>
    <li>If the <tt>acr</tt> Claim was requested, the
        Client SHOULD check that the asserted Claim Value is appropriate.
        The meaning and processing of
        <tt>acr</tt> Claim Values is out of scope for this specification.
    </li>
    <li>
        If the <tt>auth_time</tt> Claim was requested,
        either through a specific request for this Claim
        or by using the <tt>max_age</tt> parameter,
        the Client SHOULD check the <tt>auth_time</tt> Claim
        value and request re-authentication if it determines too much time
        has elapsed since the last End-User authentication.

    </li>
</ol>
<p>

</p>
<a name="CodeFlowTokenValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.1.3.8"></a>

<h3>3.1.3.8.&nbsp;
    Access Token Validation</h3>

<p>
    When using the Authorization Code Flow,
    if the ID Token contains an <tt>at_hash</tt> Claim,
    the Client MAY use it to validate the Access Token
    in the same manner as for the Implicit Flow,
    as defined in <a class="info" href="#ImplicitTokenValidation">Section&nbsp;3.2.2.9<span> (</span><span
        class="info">Access Token Validation</span><span>)</span></a>,
    but using the ID Token and Access Token returned from the Token Endpoint.

</p>
<a name="ImplicitFlowAuth"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2"></a>

<h3>3.2.&nbsp;
    Authentication using the Implicit Flow</h3>

<p>
    This section describes how to perform authentication using the Implicit Flow.
    When using the Implicit Flow,
    all tokens are returned from the Authorization Endpoint;
    the Token Endpoint is not used.

</p>

<p>The Implicit Flow is mainly used by Clients implemented in a browser
    using a scripting language. The Access Token and ID Token are returned
    directly to the Client, which may expose them to the End-User and
    applications that have access to the End-User's User Agent.
    The Authorization Server does not perform Client Authentication.

</p>
<a name="ImplicitFlowSteps"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.1"></a>

<h3>3.2.1.&nbsp;
    Implicit Flow Steps</h3>

<p>The Implicit Flow follows the following steps:
</p>

<p>
</p>
<ol class="text">
    <li>Client prepares an Authentication Request containing the desired
        request parameters.
    </li>
    <li>Client sends the request to the Authorization Server.
    </li>
    <li>Authorization Server Authenticates the End-User.
    </li>
    <li>Authorization Server obtains End-User Consent/Authorization.
    </li>
    <li>Authorization Server sends the End-User back to the Client with
        an ID Token and, if requested, an Access Token.
    </li>
    <li>Client validates the ID token and retrieves the End-User's
        Subject Identifier.
    </li>
</ol>
<p>

</p>
<a name="ImplicitAuthorizationEndpoint"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2"></a>

<h3>3.2.2.&nbsp;
    Authorization Endpoint</h3>

<p>
    When using the Implicit Flow, the Authorization Endpoint is used
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
        class="info">Authorization Endpoint</span><span>)</span></a>,
    with the exception of the differences specified in this section.

</p>
<a name="ImplicitAuthRequest"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.1"></a>

<h3>3.2.2.1.&nbsp;
    Authentication Request</h3>

<p>
    Authentication Requests are made
    as defined in <a class="info" href="#AuthRequest">Section&nbsp;3.1.2.1<span> (</span><span
        class="info">Authentication Request</span><span>)</span></a>,
    except that these Authentication Request parameters
    are used as follows:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>response_type</dt>
        <dd>

            REQUIRED.
            OAuth 2.0 Response Type value that determines
            the authorization processing flow to be used,
            including what parameters are returned from the endpoints used.
            When using the Implicit Flow, this value is
            <tt>id_token&nbsp;token</tt> or
            <tt>id_token</tt>.
            The meanings of both of these values are defined in
            <a class="info" href="#OAuth.Responses">OAuth 2.0
                Multiple Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>
            [OAuth.Responses].
            No Access Token is returned when the value is
            <tt>id_token</tt>.

        </dd>
        <dt></dt>
        <dd>
            NOTE: While OAuth 2.0 also defines the
            <tt>token</tt> Response Type value
            for the Implicit Flow, OpenID Connect does not use this Response Type,
            since no ID Token would be returned.

        </dd>
        <dt>redirect_uri</dt>
        <dd>

            REQUIRED.
            Redirection URI to which the response will be sent.
            This URI MUST exactly match one of the Redirection URI values
            for the Client pre-registered at the OpenID Provider,
            with the matching performed as described in
            Section 6.2.1 of <a class="info" href="#RFC3986">[RFC3986]<span> (</span><span
                class="info">Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January&nbsp;2005.</span><span>)</span></a>
            (Simple String Comparison).
            When using this flow, the Redirection URI
            MUST NOT use the <tt>http</tt> scheme
            unless the Client is a native application, in which case it MAY
            use the <tt>http:</tt> scheme with
            <tt>localhost</tt> as the hostname.

        </dd>
        <dt>nonce</dt>
        <dd>

            REQUIRED.
            String value used to associate a Client session
            with an ID Token, and to mitigate replay attacks.
            The value is passed through unmodified from the Authentication Request to the ID Token.
            Sufficient entropy MUST be present in the
            <tt>nonce</tt> values used to prevent
            attackers from guessing values.
            For implementation notes, see <a class="info"
                                             href="#NonceNotes">Section&nbsp;15.5.2<span> (</span><span
                class="info">Nonce Implementation Notes</span><span>)</span></a>.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    The following is a non-normative example request using the Implicit Flow
    that would be sent by the User Agent to the Authorization Server
    in response to a corresponding HTTP 302 redirect response by the Client
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /authorize?
    response_type=id_token%20token
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &amp;scope=openid%20profile
    &amp;state=af0ifjsldkj
    &amp;nonce=n-0S6_WzA2Mj HTTP/1.1
  Host: server.example.com
</pre>
</div>
<a name="ImplicitValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.2"></a>

<h3>3.2.2.2.&nbsp;
    Authentication Request Validation</h3>

<p>
    When using the Implicit Flow, the Authentication Request is validated
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#AuthRequestValidation">Section&nbsp;3.1.2.2<span> (</span><span
        class="info">Authentication Request Validation</span><span>)</span></a>.

</p>
<a name="ImplicitAuthenticates"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.3"></a>

<h3>3.2.2.3.&nbsp;
    Authorization Server Authenticates End-User</h3>

<p>
    When using the Implicit Flow, End-User Authentication is performed
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#Authenticates">Section&nbsp;3.1.2.3<span> (</span><span
        class="info">Authorization Server Authenticates End-User</span><span>)</span></a>.

</p>
<a name="ImplicitConsent"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.4"></a>

<h3>3.2.2.4.&nbsp;
    Authorization Server Obtains End-User Consent/Authorization</h3>

<p>
    When using the Implicit Flow, End-User Consent is obtained
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#Consent">Section&nbsp;3.1.2.4<span> (</span><span
        class="info">Authorization Server Obtains End-User Consent/Authorization</span><span>)</span></a>.

</p>
<a name="ImplicitAuthResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.5"></a>

<h3>3.2.2.5.&nbsp;
    Successful Authentication Response</h3>

<p>
    When using the Implicit Flow, Authentication Responses are made
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#AuthResponse">Section&nbsp;3.1.2.5<span> (</span><span
        class="info">Successful Authentication Response</span><span>)</span></a>,
    with the exception of the differences specified in this section.

</p>

<p>
    When using the Implicit Flow,
    all response parameters are added to the fragment component
    of the Redirection URI, as specified in
    <a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
        Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>
    [OAuth.Responses],
    unless a different Response Mode was specified.

</p>

<p>
    These parameters are returned from the Authorization Endpoint:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>access_token</dt>
        <dd>

            OAuth 2.0 Access Token.
            This is returned
            unless the <tt>response_type</tt> value used is
            <tt>id_token</tt>.

        </dd>
        <dt>token_type</dt>
        <dd>

            OAuth 2.0 Token Type value.
            The value MUST be <tt>Bearer</tt> or
            another <tt>token_type</tt> value that the Client
            has negotiated with the Authorization Server.
            Clients implementing this profile MUST support the <a class="info"
                                                                  href="#RFC6750">OAuth
            2.0 Bearer Token Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October&nbsp;2012.</span><span>)</span></a>
            [RFC6750] specification.
            This profile only describes the use of bearer tokens.
            This is returned in the same cases as
            <tt>access_token</tt> is.

        </dd>
        <dt>id_token</dt>
        <dd>

            REQUIRED.
            ID Token.

        </dd>
        <dt>state</dt>
        <dd>

            OAuth 2.0 state value.
            REQUIRED if the
            <tt>state</tt> parameter is present in the
            Authorization Request. Clients MUST verify that the
            <tt>state</tt> value is equal to the
            value of <tt>state</tt> parameter in the
            Authorization Request.

        </dd>
        <dt>expires_in</dt>
        <dd>

            OPTIONAL.
            Expiration time of the Access Token in seconds
            since the response was generated.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    Per Section 4.2.2 of <a class="info" href="#RFC6749">OAuth
    2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749],
    no <tt>code</tt> result is returned
    when using the Implicit Flow.

</p>

<p>The following is a non-normative example
    of a successful response using the Implicit Flow
    (with line wraps for the display purposes only):
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=SlAV32hkKG
    &amp;token_type=bearer
    &amp;id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &amp;expires_in=3600
    &amp;state=af0ifjsldkj
</pre>
</div>
<a name="ImplicitAuthError"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.6"></a>

<h3>3.2.2.6.&nbsp;
    Authentication Error Response</h3>

<p>
    When using the Implicit Flow, Authorization Error Responses are made
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
        class="info">Authentication Error Response</span><span>)</span></a>,
    with the exception of the differences specified in this section.

</p>

<p>
    If the End-User denies the request or the End-User authentication
    fails, the Authorization Server MUST return the error
    Authorization Response in the
    fragment component of the Redirection URI,
    as defined in 4.2.2.1 of
    <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749] and
    <a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
        Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>
    [OAuth.Responses],
    unless a different Response Mode was specified.

</p>
<a name="ImplicitCallback"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.7"></a>

<h3>3.2.2.7.&nbsp;
    Redirect URI Fragment Handling</h3>

<p>
    Since response parameters are returned in the Redirection URI fragment value,
    the Client needs to have the User Agent parse the fragment encoded values
    and pass them to on to the Client's processing logic for consumption.
    See <a class="info"
           href="#FragmentNotes">Section&nbsp;15.5.3<span> (</span><span
        class="info">Redirect URI Fragment Handling Implementation Notes</span><span>)</span></a> for implementation
    notes
    on URI fragment handling.

</p>
<a name="ImplicitAuthResponseValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.8"></a>

<h3>3.2.2.8.&nbsp;
    Authentication Response Validation</h3>

<p>
    When using the Implicit Flow,
    the Client MUST validate the response as follows:
</p>
<ol class="text">
    <li>
        Verify that the response conforms to Section 5 of
        <a class="info"
           href="#OAuth.Responses">[OAuth.Responses]<span> (</span><span
                class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>.

    </li>
    <li>
        Follow the validation rules in RFC 6749,
        especially those in Sections 4.2.2 and 10.12.

    </li>
    <li>
        Follow the ID Token validation rules in <a class="info"
                                                   href="#ImplicitIDTValidation">Section&nbsp;3.2.2.11<span> (</span><span
            class="info">ID Token Validation</span><span>)</span></a>.

    </li>
    <li>
        Follow the Access Token validation rules in <a class="info"
                                                       href="#ImplicitTokenValidation">Section&nbsp;3.2.2.9<span> (</span><span
            class="info">Access Token Validation</span><span>)</span></a>,
        unless the <tt>response_type</tt> value used is
        <tt>id_token</tt>.

    </li>
</ol>
<p>

</p>
<a name="ImplicitTokenValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.9"></a>

<h3>3.2.2.9.&nbsp;
    Access Token Validation</h3>

<p>To validate an Access Token issued from the Authorization Endpoint with an ID Token,
    the Client SHOULD do the following:
</p>

<p>
</p>
<ol class="text">
    <li>Hash the octets of the ASCII representation of
        the <tt>access_token</tt>
        with the hash algorithm specified in <a class="info"
                                                href="#JWA">JWA<span> (</span><span
                class="info">Jones, M., “JSON Web Algorithms (JWA),” July&nbsp;2014.</span><span>)</span></a> [JWA] for
        the
        <tt>alg</tt> Header Parameter
        of the ID Token's JOSE Header.
        For instance, if the <tt>alg</tt> is
        <tt>RS256</tt>,
        the hash algorithm used is SHA-256.

    </li>
    <li>Take the left-most half of the hash and base64url encode it.
    </li>
    <li>
        The value of <tt>at_hash</tt> in the ID Token MUST
        match the value produced in the previous step.

    </li>
</ol>
<p>

</p>
<a name="ImplicitIDToken"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.10"></a>

<h3>3.2.2.10.&nbsp;
    ID Token</h3>

<p>
    The contents of the ID Token are as described in <a class="info"
                                                        href="#IDToken">Section&nbsp;2<span> (</span><span
        class="info">ID Token</span><span>)</span></a>.
    When using the Implicit Flow,
    these additional requirements for the following ID Token Claims apply:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>nonce</dt>
        <dd>

            Use of the <tt>nonce</tt> Claim is REQUIRED
            for this flow.

        </dd>
        <dt>at_hash</dt>
        <dd>

            Access Token hash value.
            Its value is the base64url encoding of the left-most half of the
            hash of the octets of the ASCII representation of the
            <tt>access_token</tt> value,
            where the hash algorithm used is the hash algorithm
            used in the <tt>alg</tt> Header Parameter
            of the ID Token's JOSE Header.
            For instance, if the <tt>alg</tt> is
            <tt>RS256</tt>, hash the
            <tt>access_token</tt> value
            with SHA-256, then take the left-most 128 bits and base64url encode them.
            The <tt>at_hash</tt> value is a case sensitive string.

        </dd>
        <dt></dt>
        <dd>
            If the ID Token is issued from the Authorization Endpoint with an
            <tt>access_token</tt> value,
            which is the case for the <tt>response_type</tt> value
            <tt>id_token&nbsp;token</tt>,
            this is REQUIRED;
            it MAY NOT be used when no Access Token is issued,
            which is the case for the <tt>response_type</tt> value
            <tt>id_token</tt>.

        </dd>
    </dl>
</blockquote>
<p>

</p>
<a name="ImplicitIDTValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.2.2.11"></a>

<h3>3.2.2.11.&nbsp;
    ID Token Validation</h3>

<p>
    When using the Implicit Flow, the contents of the ID Token MUST be validated
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#IDTokenValidation">Section&nbsp;3.1.3.7<span> (</span><span
        class="info">ID Token Validation</span><span>)</span></a>,
    with the exception of the differences specified in this section.

</p>

<p>
</p>
<ol class="text">
    <li>
        The Client MUST validate the signature of the ID Token according to
        <a class="info" href="#JWS">JWS<span> (</span><span
                class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>
        [JWS] using the algorithm specified in the
        <tt>alg</tt> Header Parameter of the JOSE Header.

    </li>
    <li>
        The value of the <tt>nonce</tt>
        Claim MUST be checked to verify that
        it is the same value as the one that was sent in the Authentication Request.
        The Client SHOULD check the <tt>nonce</tt> value
        for replay attacks.
        The precise method for detecting replay attacks is Client specific.

    </li>
</ol>
<p>

</p>
<a name="HybridFlowAuth"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3"></a>

<h3>3.3.&nbsp;
    Authentication using the Hybrid Flow</h3>

<p>
    This section describes how to perform authentication using the Hybrid Flow.
    When using the Hybrid Flow,
    some tokens are returned from the Authorization Endpoint
    and others are returned from the Token Endpoint.
    The mechanisms for returning tokens in the Hybrid Flow are specified in
    <a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
        Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>
    [OAuth.Responses].

</p>
<a name="HybridFlowSteps"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.1"></a>

<h3>3.3.1.&nbsp;
    Hybrid Flow Steps</h3>

<p>The Hybrid Flow follows the following steps:
</p>

<p>
</p>
<ol class="text">
    <li>Client prepares an Authentication Request containing the desired
        request parameters.
    </li>
    <li>Client sends the request to the Authorization Server.
    </li>
    <li>Authorization Server Authenticates the End-User.
    </li>
    <li>Authorization Server obtains End-User Consent/Authorization.
    </li>
    <li>
        Authorization Server sends the End-User back to the Client with
        an Authorization Code and, depending on the Response Type,
        one or more additional parameters.

    </li>
    <li>Client requests a response using the Authorization Code at the
        Token Endpoint.
    </li>
    <li>Client receives a response that contains an ID Token
        and Access Token in the response body.
    </li>
    <li>Client validates the ID Token and retrieves the End-User's
        Subject Identifier.
    </li>
</ol>
<p>

</p>
<a name="HybridAuthorizationEndpoint"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2"></a>

<h3>3.3.2.&nbsp;
    Authorization Endpoint</h3>

<p>
    When using the Hybrid Flow, the Authorization Endpoint is used
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
        class="info">Authorization Endpoint</span><span>)</span></a>,
    with the exception of the differences specified in this section.

</p>
<a name="HybridAuthRequest"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.1"></a>

<h3>3.3.2.1.&nbsp;
    Authentication Request</h3>

<p>
    Authentication Requests are made
    as defined in <a class="info" href="#AuthRequest">Section&nbsp;3.1.2.1<span> (</span><span
        class="info">Authentication Request</span><span>)</span></a>,
    except that these Authentication Request parameters
    are used as follows:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>response_type</dt>
        <dd>

            REQUIRED.
            OAuth 2.0 Response Type value that determines
            the authorization processing flow to be used,
            including what parameters are returned from the endpoints used.
            When using the Hybrid Flow, this value is
            <tt>code&nbsp;id_token</tt>,
            <tt>code&nbsp;token</tt>, or
            <tt>code&nbsp;id_token&nbsp;token</tt>.
            The meanings of these values are defined in
            <a class="info" href="#OAuth.Responses">OAuth 2.0
                Multiple Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>
            [OAuth.Responses].

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    The following is a non-normative example request using the Hybrid Flow
    that would be sent by the User Agent to the Authorization Server
    in response to a corresponding HTTP 302 redirect response by the Client
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /authorize?
    response_type=code%20id_token
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &amp;scope=openid%20profile%20email
    &amp;nonce=n-0S6_WzA2Mj
    &amp;state=af0ifjsldkj HTTP/1.1
  Host: server.example.com
</pre>
</div>
<a name="HybridValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.2"></a>

<h3>3.3.2.2.&nbsp;
    Authentication Request Validation</h3>

<p>
    When using the Hybrid Flow, the Authentication Request is validated
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#AuthRequestValidation">Section&nbsp;3.1.2.2<span> (</span><span
        class="info">Authentication Request Validation</span><span>)</span></a>.

</p>
<a name="HybridAuthenticates"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.3"></a>

<h3>3.3.2.3.&nbsp;
    Authorization Server Authenticates End-User</h3>

<p>
    When using the Hybrid Flow, End-User Authentication is performed
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#Authenticates">Section&nbsp;3.1.2.3<span> (</span><span
        class="info">Authorization Server Authenticates End-User</span><span>)</span></a>.

</p>
<a name="HybridConsent"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.4"></a>

<h3>3.3.2.4.&nbsp;
    Authorization Server Obtains End-User Consent/Authorization</h3>

<p>
    When using the Hybrid Flow, End-User Consent is obtained
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#Consent">Section&nbsp;3.1.2.4<span> (</span><span
        class="info">Authorization Server Obtains End-User Consent/Authorization</span><span>)</span></a>.

</p>
<a name="HybridAuthResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.5"></a>

<h3>3.3.2.5.&nbsp;
    Successful Authentication Response</h3>

<p>
    When using the Hybrid Flow, Authentication Responses are made
    in the same manner as for the Implicit Flow,
    as defined in <a class="info" href="#ImplicitAuthResponse">Section&nbsp;3.2.2.5<span> (</span><span
        class="info">Successful Authentication Response</span><span>)</span></a>,
    with the exception of the differences specified in this section.

</p>

<p>
    These Authorization Endpoint results are used in the following manner:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>access_token</dt>
        <dd>

            OAuth 2.0 Access Token.
            This is returned
            when the <tt>response_type</tt> value used is
            <tt>code&nbsp;token</tt>,
            or <tt>code&nbsp;id_token&nbsp;token</tt>.
            (A <tt>token_type</tt> value is also returned in the same cases.)

        </dd>
        <dt>id_token</dt>
        <dd>

            ID Token.
            This is returned
            when the <tt>response_type</tt> value used is
            <tt>code&nbsp;id_token</tt> or
            <tt>code&nbsp;id_token&nbsp;token</tt>.

        </dd>
        <dt>code</dt>
        <dd>

            Authorization Code.
            This is always returned when using the Hybrid Flow.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>The following is a non-normative example
    of a successful response using the Hybrid Flow
    (with line wraps for the display purposes only):
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=SplxlOBeZQQYbYS6WxSbIA
    &amp;id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &amp;state=af0ifjsldkj
</pre>
</div>
<a name="HybridAuthError"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.6"></a>

<h3>3.3.2.6.&nbsp;
    Authentication Error Response</h3>

<p>
    When using the Hybrid Flow, Authorization Error Responses are made
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
        class="info">Authentication Error Response</span><span>)</span></a>,
    with the exception of the differences specified in this section.

</p>

<p>
    If the End-User denies the request or the End-User authentication
    fails, the Authorization Server MUST return the error
    Authorization Response in the
    fragment component of the Redirection URI,
    as defined in 4.2.2.1 of
    <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749] and
    <a class="info" href="#OAuth.Responses">OAuth 2.0 Multiple
        Response Type Encoding Practices<span> (</span><span class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>
    [OAuth.Responses],
    unless a different Response Mode was specified.

</p>
<a name="HybridCallback"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.7"></a>

<h3>3.3.2.7.&nbsp;
    Redirect URI Fragment Handling</h3>

<p>
    When using the Hybrid Flow, the same requirements for
    Redirection URI fragment parameter handling apply as do for
    the Implicit Flow, as defined in <a class="info"
                                        href="#ImplicitCallback">Section&nbsp;3.2.2.7<span> (</span><span
        class="info">Redirect URI Fragment Handling</span><span>)</span></a>.
    Also see <a class="info" href="#FragmentNotes">Section&nbsp;15.5.3<span> (</span><span
        class="info">Redirect URI Fragment Handling Implementation Notes</span><span>)</span></a> for implementation
    notes
    on URI fragment handling.

</p>
<a name="HybridAuthResponseValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.8"></a>

<h3>3.3.2.8.&nbsp;
    Authentication Response Validation</h3>

<p>
    When using the Hybrid Flow,
    the Client MUST validate the response as follows:
</p>
<ol class="text">
    <li>
        Verify that the response conforms to Section 5 of
        <a class="info"
           href="#OAuth.Responses">[OAuth.Responses]<span> (</span><span
                class="info">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February&nbsp;2014.</span><span>)</span></a>.

    </li>
    <li>
        Follow the validation rules in RFC 6749,
        especially those in Sections 4.2.2 and 10.12.

    </li>
    <li>
        Follow the ID Token validation rules in <a class="info"
                                                   href="#HybridIDTValidation">Section&nbsp;3.3.2.12<span> (</span><span
            class="info">ID Token Validation</span><span>)</span></a>
        when the <tt>response_type</tt> value used is
        <tt>code&nbsp;id_token</tt> or
        <tt>code&nbsp;id_token&nbsp;token</tt>.

    </li>
    <li>
        Follow the Access Token validation rules in <a class="info"
                                                       href="#HybridTokenValidation">Section&nbsp;3.3.2.9<span> (</span><span
            class="info">Access Token Validation</span><span>)</span></a>
        when the <tt>response_type</tt> value used is
        <tt>code&nbsp;token</tt> or
        <tt>code&nbsp;id_token&nbsp;token</tt>.

    </li>
    <li>
        Follow the Authorization Code validation rules in <a class="info"
                                                             href="#CodeValidation">Section&nbsp;3.3.2.10<span> (</span><span
            class="info">Authorization Code Validation</span><span>)</span></a>
        when the <tt>response_type</tt> value used is
        <tt>code&nbsp;id_token</tt> or

        <tt>code&nbsp;id_token&nbsp;token</tt>.

    </li>
</ol>
<p>

</p>
<a name="HybridTokenValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.9"></a>

<h3>3.3.2.9.&nbsp;
    Access Token Validation</h3>

<p>
    When using the Hybrid Flow, Access Tokens
    returned from the Authorization Endpoint are validated
    in the same manner as for the Implicit Flow,
    as defined in <a class="info" href="#ImplicitTokenValidation">Section&nbsp;3.2.2.9<span> (</span><span
        class="info">Access Token Validation</span><span>)</span></a>.

</p>
<a name="CodeValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.10"></a>

<h3>3.3.2.10.&nbsp;
    Authorization Code Validation</h3>

<p>To validate an Authorization Code issued from the Authorization Endpoint with an ID Token,
    the Client SHOULD do the following:
</p>

<p>
</p>
<ol class="text">
    <li>Hash the octets of the ASCII representation of
        the <tt>code</tt>
        with the hash algorithm specified in <a class="info"
                                                href="#JWA">JWA<span> (</span><span
                class="info">Jones, M., “JSON Web Algorithms (JWA),” July&nbsp;2014.</span><span>)</span></a> [JWA] for
        the
        <tt>alg</tt> Header Parameter
        of the ID Token's JOSE Header.
        For instance, if the <tt>alg</tt> is
        <tt>RS256</tt>,
        the hash algorithm used is SHA-256.

    </li>
    <li>Take the left-most half of the hash and base64url encode it.
    </li>
    <li>The value of <tt>c_hash</tt> in the ID Token MUST
        match the value produced in the previous step if <tt>c_hash</tt>
        is present in the ID Token.
    </li>
</ol>
<p>

</p>
<a name="HybridIDToken"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.11"></a>

<h3>3.3.2.11.&nbsp;
    ID Token</h3>

<p>
    The contents of the ID Token are as described in <a class="info"
                                                        href="#IDToken">Section&nbsp;2<span> (</span><span
        class="info">ID Token</span><span>)</span></a>.
    When using the Hybrid Flow,
    these additional requirements for the following ID Token Claims apply
    to an ID Token returned from the Authorization Endpoint:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>nonce</dt>
        <dd>

            Use of the <tt>nonce</tt> Claim is REQUIRED
            for this flow.

        </dd>
        <dt>at_hash</dt>
        <dd>

            Access Token hash value.
            Its value is the base64url encoding of the left-most half of the
            hash of the octets of the ASCII representation of the
            <tt>access_token</tt> value,
            where the hash algorithm used is the hash algorithm
            used in the <tt>alg</tt> Header Parameter
            of the ID Token's JOSE Header.
            For instance, if the <tt>alg</tt> is
            <tt>RS256</tt>, hash the
            <tt>access_token</tt> value
            with SHA-256, then take the left-most 128 bits and base64url encode them.
            The <tt>at_hash</tt> value is a case sensitive string.

        </dd>
        <dt></dt>
        <dd>
            If the ID Token is issued from the Authorization Endpoint with an
            <tt>access_token</tt> value,
            which is the case for the <tt>response_type</tt> value
            <tt>code&nbsp;id_token&nbsp;token</tt>,
            this is REQUIRED; otherwise, its inclusion is OPTIONAL.

        </dd>
        <dt>c_hash</dt>
        <dd>

            Code hash value.
            Its value is the base64url encoding of the left-most half of the
            hash of the octets of the ASCII representation of the
            <tt>code</tt> value,
            where the hash algorithm used is the hash algorithm
            used in the <tt>alg</tt> Header Parameter
            of the ID Token's JOSE Header.
            For instance, if the <tt>alg</tt> is
            <tt>HS512</tt>, hash the
            <tt>code</tt> value
            with SHA-512, then take the left-most 256 bits and base64url encode them.
            The <tt>c_hash</tt> value is a case sensitive string.

        </dd>
        <dt></dt>
        <dd>
            If the ID Token is issued from the Authorization Endpoint with a
            <tt>code</tt>,
            which is the case for the <tt>response_type</tt> values
            <tt>code&nbsp;id_token</tt> and
            <tt>code&nbsp;id_token&nbsp;token</tt>,
            this is REQUIRED; otherwise, its inclusion is OPTIONAL.

        </dd>
    </dl>
</blockquote>
<p>

</p>
<a name="HybridIDTValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.2.12"></a>

<h3>3.3.2.12.&nbsp;
    ID Token Validation</h3>

<p>
    When using the Hybrid Flow, the contents of an ID Token
    returned from the Authorization Endpoint MUST be validated
    in the same manner as for the Implicit Flow,
    as defined in <a class="info" href="#ImplicitIDTValidation">Section&nbsp;3.2.2.11<span> (</span><span
        class="info">ID Token Validation</span><span>)</span></a>.

</p>
<a name="HybridTokenEndpoint"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.3"></a>

<h3>3.3.3.&nbsp;
    Token Endpoint</h3>

<p>
    When using the Hybrid Flow, the Token Endpoint is used
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#TokenEndpoint">Section&nbsp;3.1.3<span> (</span><span
        class="info">Token Endpoint</span><span>)</span></a>,
    with the exception of the differences specified in this section.

</p>
<a name="HybridTokenRequest"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.3.1"></a>

<h3>3.3.3.1.&nbsp;
    Token Request</h3>

<p>
    When using the Hybrid Flow, Token Requests are made
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#TokenRequest">Section&nbsp;3.1.3.1<span> (</span><span
        class="info">Token Request</span><span>)</span></a>.

</p>
<a name="HybridTokenRequestValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.3.2"></a>

<h3>3.3.3.2.&nbsp;
    Token Request Validation</h3>

<p>
    When using the Hybrid Flow, Token Requests are validated
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#TokenRequestValidation">Section&nbsp;3.1.3.2<span> (</span><span
        class="info">Token Request Validation</span><span>)</span></a>.

</p>
<a name="HybridTokenResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.3.3"></a>

<h3>3.3.3.3.&nbsp;
    Successful Token Response</h3>

<p>
    When using the Hybrid Flow, Token Responses are made
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#TokenResponse">Section&nbsp;3.1.3.3<span> (</span><span
        class="info">Successful Token Response</span><span>)</span></a>.

</p>
<a name="HybridTokenErrorResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.3.4"></a>

<h3>3.3.3.4.&nbsp;
    Token Error Response</h3>

<p>
    When using the Hybrid Flow, Token Error Responses are made
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#TokenErrorResponse">Section&nbsp;3.1.3.4<span> (</span><span
        class="info">Token Error Response</span><span>)</span></a>.

</p>
<a name="HybridTokenResponseValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.3.5"></a>

<h3>3.3.3.5.&nbsp;
    Token Response Validation</h3>

<p>
    When using the Hybrid Flow, Token Responses are validated
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#TokenResponseValidation">Section&nbsp;3.1.3.5<span> (</span><span
        class="info">Token Response Validation</span><span>)</span></a>.

</p>
<a name="HybridIDToken2"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.3.6"></a>

<h3>3.3.3.6.&nbsp;
    ID Token</h3>

<p>
    When using the Hybrid Flow, the contents of an ID Token
    returned from the Token Endpoint are
    the same as for an ID Token returned from the Authorization Endpoint,
    as defined in <a class="info" href="#HybridIDToken">Section&nbsp;3.3.2.11<span> (</span><span
        class="info">ID Token</span><span>)</span></a>,
    with the exception of the differences specified in this section.

</p>

<p>
    If an ID Token is returned from both the Authorization Endpoint
    and from the Token Endpoint,
    which is the case for the <tt>response_type</tt> values
    <tt>code&nbsp;id_token</tt> and
    <tt>code&nbsp;id_token&nbsp;token</tt>,
    the <tt>iss</tt> and <tt>sub</tt>
    Claim Values MUST be identical in both ID Tokens.
    All Claims about the Authentication event present in either
    SHOULD be present in both.
    If either ID Token contains Claims about the End-User,
    any that are present in both SHOULD have the same values in both.
    Note that the OP MAY choose to return fewer Claims about the End-User
    from the Authorization Endpoint, for instance, for privacy reasons.
    The <tt>at_hash</tt>
    and <tt>c_hash</tt> Claims
    MAY be omitted from the ID Token returned from the Token Endpoint
    even when these Claims are
    present in the ID Token returned from the Authorization Endpoint,
    because the ID Token and Access Token values returned from
    the Token Endpoint are already cryptographically bound together
    by the TLS encryption performed by the Token Endpoint.

</p>
<a name="HybridIDTValidation2"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.3.7"></a>

<h3>3.3.3.7.&nbsp;
    ID Token Validation</h3>

<p>
    When using the Hybrid Flow, the contents of an ID Token
    returned from the Token Endpoint MUST be validated
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#IDTokenValidation">Section&nbsp;3.1.3.7<span> (</span><span
        class="info">ID Token Validation</span><span>)</span></a>.

</p>
<a name="HybridAccessToken2"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.3.8"></a>

<h3>3.3.3.8.&nbsp;
    Access Token</h3>

<p>
    If an Access Token is returned from both the Authorization Endpoint
    and from the Token Endpoint,
    which is the case for the <tt>response_type</tt> values
    <tt>code&nbsp;token</tt> and
    <tt>code&nbsp;id_token&nbsp;token</tt>,
    their values MAY be the same
    or they MAY be different.
    Note that different Access Tokens might be returned
    be due to the different security characteristics
    of the two endpoints and the lifetimes and
    the access to resources granted by them might also be different.

</p>
<a name="HybridTokenValidation2"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.3.3.3.9"></a>

<h3>3.3.3.9.&nbsp;
    Access Token Validation</h3>

<p>
    When using the Hybrid Flow, the Access Token
    returned from the Token Endpoint
    is validated
    in the same manner as for the Authorization Code Flow,
    as defined in <a class="info" href="#CodeFlowTokenValidation">Section&nbsp;3.1.3.8<span> (</span><span
        class="info">Access Token Validation</span><span>)</span></a>.

</p>
<a name="ThirdPartyInitiatedLogin"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.4"></a>

<h3>4.&nbsp;
    Initiating Login from a Third Party</h3>

<p>
    In some cases, the login flow is initiated by an OpenID Provider
    or another party, rather than the Relying Party.
    In this case, the initiator redirects to the RP at its login initiation endpoint,
    which requests that the RP send an Authentication Request to a specified OP.
    This login initiation endpoint can be a deep link at the RP,
    rather than a default landing page.
    RPs supporting
    <a class="info" href="#OpenID.Registration">OpenID Connect
        Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November&nbsp;2014.</span><span>)</span></a>
    [OpenID.Registration]
    register this endpoint value using the
    <tt>initiate_login_uri</tt> Registration parameter.

</p>

<p>
    The party initiating the login request does so by redirecting
    to the login initiation endpoint at the RP, passing the following parameters:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>iss</dt>
        <dd>

            REQUIRED.
            Issuer Identifier for the OP that the RP is to send
            the Authentication Request to.
            Its value MUST be a URL using the <tt>https</tt> scheme.

        </dd>
        <dt>login_hint</dt>
        <dd>

            OPTIONAL.
            Hint to the Authorization Server
            about the login identifier the End-User might use to log in.
            If the client receives a value for this string-valued parameter,
            it MUST include it in the Authentication Request
            as the <tt>login_hint</tt> parameter value.

        </dd>
        <dt>target_link_uri</dt>
        <dd>

            OPTIONAL.
            URL that the RP is requested to redirect to after authentication.
            RPs MUST verify the value of the
            <tt>target_link_uri</tt> to prevent being used as
            an open redirector to external sites.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    The parameters can either be passed as query parameters using
    the HTTP <tt>GET</tt> method
    or be passed as HTML form values that are auto-submitted in the User Agent,
    and thus are transmitted via the HTTP <tt>POST</tt> method.

</p>

<p>
    Other parameters MAY be sent, if defined by extensions.
    Any parameters used that are not understood MUST be ignored by the Client.

</p>

<p>
    Clients SHOULD employ frame busting and other techniques to prevent
    End-Users from being logged in by third party sites without their knowledge
    through attacks such as Clickjacking.
    Refer to Section 4.4.1.9 of <a class="info" href="#RFC6819">[RFC6819]<span> (</span><span
        class="info">Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January&nbsp;2013.</span><span>)</span></a>
    for more details.

</p>
<a name="Claims"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5"></a>

<h3>5.&nbsp;
    Claims</h3>

<p>
    This section specifies how the Client can obtain Claims about the End-User
    and the Authentication event.
    It also defines a standard set of basic profile Claims.
    Pre-defined sets of Claims can be requested using specific scope values
    or individual Claims can be requested using the
    <tt>claims</tt> request parameter.
    The Claims can come directly from the OpenID Provider
    or from distributed sources as well.

</p>
<a name="StandardClaims"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.1"></a>

<h3>5.1.&nbsp;
    Standard Claims</h3>

<p>This specification defines a set of standard Claims.
    They can be requested to be returned either in the
    UserInfo Response, per <a class="info" href="#UserInfoResponse">Section&nbsp;5.3.2<span> (</span><span
            class="info">Successful UserInfo Response</span><span>)</span></a>,
    or in the ID Token, per <a class="info" href="#IDToken">Section&nbsp;2<span> (</span><span
            class="info">ID Token</span><span>)</span></a>.

</p><br>
<hr class="insert">
<a name="ClaimTable"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <colgroup>
        <col align="left">
        <col align="left">
        <col align="left">
    </colgroup>
    <tbody>
    <tr>
        <th align="left">Member</th>
        <th align="left">Type</th>
        <th align="left">Description</th>
    </tr>
    <tr>
        <td align="left">sub</td>
        <td align="left">string</td>
        <td align="left">Subject - Identifier for the End-User at the Issuer.</td>
    </tr>
    <tr>
        <td align="left">name</td>
        <td align="left">string</td>
        <td align="left">
            End-User's full name in displayable form including all name parts,
            possibly including titles and suffixes,
            ordered according to the End-User's locale and preferences.
        </td>
    </tr>
    <tr>
        <td align="left">given_name</td>
        <td align="left">string</td>
        <td align="left">
            Given name(s) or first name(s) of the End-User.
            Note that in some cultures, people can have multiple given names;
            all can be present, with the names being separated by space characters.
        </td>
    </tr>
    <tr>
        <td align="left">family_name</td>
        <td align="left">string</td>
        <td align="left">
            Surname(s) or last name(s) of the End-User.
            Note that in some cultures, people can have multiple family names
            or no family name;
            all can be present, with the names being separated by space characters.
        </td>
    </tr>
    <tr>
        <td align="left">middle_name</td>
        <td align="left">string</td>
        <td align="left">
            Middle name(s) of the End-User.
            Note that in some cultures, people can have multiple middle names;
            all can be present, with the names being separated by space characters.
            Also note that in some cultures, middle names are not used.
        </td>
    </tr>
    <tr>
        <td align="left">nickname</td>
        <td align="left">string</td>
        <td align="left">Casual name of the End-User that may or may not be the same as the
            <tt>given_name</tt>. For instance, a <tt>nickname</tt> value of <tt>Mike</tt>
            might be returned alongside a <tt>given_name</tt>
            value of <tt>Michael</tt>.
        </td>
    </tr>
    <tr>
        <td align="left">preferred_username</td>
        <td align="left">string</td>
        <td align="left">Shorthand name by which the End-User wishes to be referred to at the RP, such as
            <tt>janedoe</tt> or <tt>j.doe</tt>.
            This value MAY be any valid JSON string including
            special characters such as <tt>@</tt>,
            <tt>/</tt>, or whitespace.
            The RP MUST NOT rely upon this value being unique,
            as discussed in <a class="info" href="#ClaimStability">Section&nbsp;5.7<span> (</span><span
                    class="info">Claim Stability and Uniqueness</span><span>)</span></a>.
        </td>
    </tr>
    <tr>
        <td align="left">profile</td>
        <td align="left">string</td>
        <td align="left">
            URL of the End-User's profile page.
            The contents of this Web page SHOULD be about the End-User.
        </td>
    </tr>
    <tr>
        <td align="left">picture</td>
        <td align="left">string</td>
        <td align="left">
            URL of the End-User's profile picture.
            This URL MUST refer to an image file
            (for example, a PNG, JPEG, or GIF image file),
            rather than to a Web page containing an image.
            Note that this URL SHOULD specifically reference
            a profile photo of the End-User
            suitable for displaying when describing the End-User,
            rather than an arbitrary photo taken by the End-User.
        </td>
    </tr>
    <tr>
        <td align="left">website</td>
        <td align="left">string</td>
        <td align="left">
            URL of the End-User's Web page or blog.
            This Web page SHOULD contain information published by the End-User
            or an organization that the End-User is affiliated with.
        </td>
    </tr>
    <tr>
        <td align="left">email</td>
        <td align="left">string</td>
        <td align="left">
            End-User's preferred e-mail address.
            Its value MUST conform to the <a class="info"
                                             href="#RFC5322">RFC
            5322<span> (</span><span class="info">Resnick, P., Ed., “Internet Message Format,” October&nbsp;2008.</span><span>)</span></a>
            [RFC5322]
            addr-spec syntax.
            The RP MUST NOT rely upon this value being unique,
            as discussed in <a class="info" href="#ClaimStability">Section&nbsp;5.7<span> (</span><span
                class="info">Claim Stability and Uniqueness</span><span>)</span></a>.
        </td>
    </tr>
    <tr>
        <td align="left">email_verified</td>
        <td align="left">boolean</td>
        <td align="left">
            True if the End-User's e-mail address has been verified; otherwise false.
            When this Claim Value is <tt>true</tt>,
            this means that the OP took affirmative steps
            to ensure that this e-mail address was controlled by the End-User
            at the time the verification was performed.
            The means by which an e-mail address is verified is context-specific,
            and dependent upon the trust framework or contractual agreements
            within which the parties are operating.
        </td>
    </tr>
    <tr>
        <td align="left">gender</td>
        <td align="left">string</td>
        <td align="left"> End-User's gender. Values defined by this
            specification are <tt>female</tt> and
            <tt>male</tt>. Other values MAY be used
            when neither of the defined values are applicable.
        </td>
    </tr>
    <tr>
        <td align="left">birthdate</td>
        <td align="left">string</td>
        <td align="left">End-User's birthday, represented as an
            <a class="info" href="#ISO8601-2004">ISO 8601:2004<span> (</span><span
                    class="info">International Organization for 	    Standardization, “ISO 8601:2004. Data elements and interchange formats - Information interchange - 	  Representation of dates and times,” 2004.</span><span>)</span></a>
            [ISO8601‑2004] <tt>YYYY-MM-DD</tt>
            format. The year MAY be <tt>0000</tt>, indicating that it is omitted.
            To represent only the year, <tt>YYYY</tt> format is allowed. Note that
            depending on the underlying platform's date related function, providing just year can
            result in varying month and day, so the implementers need to take this factor into account
            to correctly process the dates.
        </td>
    </tr>
    <tr>
        <td align="left">zoneinfo</td>
        <td align="left">string</td>
        <td align="left">String from zoneinfo <a class="info"
                                                 href="#zoneinfo">[zoneinfo]<span> (</span><span
                class="info">Public Domain, “The tz database,” June&nbsp;2011.</span><span>)</span></a> time zone
            database representing the End-User's time zone.
            For example, <tt>Europe/Paris</tt> or
            <tt>America/Los_Angeles</tt>.
        </td>
    </tr>
    <tr>
        <td align="left">locale</td>
        <td align="left">string</td>
        <td align="left">End-User's locale, represented as a
            <a class="info"
               href="#RFC5646">BCP47<span> (</span><span
                    class="info">Phillips, A. and M. Davis, “Tags for Identifying Languages,” September&nbsp;2009.</span><span>)</span></a>
            [RFC5646] language tag.
            This is typically an <a class="info" href="#ISO639-1">ISO
                639-1 Alpha-2<span> (</span><span class="info">International Organization for 	    Standardization, “ISO 639-1:2002. Codes for the representation of names of 	  languages -- Part 1: Alpha-2 code,” 2002.</span><span>)</span></a>
            [ISO639‑1]
            language code in
            lowercase and an <a class="info" href="#ISO3166-1">ISO
                3166-1 Alpha-2<span> (</span><span class="info">International Organization for 	    Standardization, “ISO 3166-1:1997. Codes for the representation of names of 	  countries and their subdivisions -- Part 1: Country codes,” 1997.</span><span>)</span></a>
            [ISO3166‑1]
            country code in uppercase, separated by a dash. For example,
            <tt>en-US</tt> or <tt>fr-CA</tt>.
            As a compatibility note, some implementations have used an underscore
            as the separator rather than a dash, for example,
            <tt>en_US</tt>; Relying Parties MAY choose to
            accept this locale syntax as well.
        </td>
    </tr>
    <tr>
        <td align="left">phone_number</td>
        <td align="left">string</td>
        <td align="left">
            End-User's preferred telephone number. <a class="info"
                                                      href="#E.164">E.164<span> (</span><span
                class="info">International Telecommunication Union, “E.164: The international public telecommunication numbering plan,” 2010.</span><span>)</span></a>
            [E.164]
            is RECOMMENDED as the format of this Claim,
            for example, <tt>+1 (425) 555-1212</tt>
            or <tt>+56 (2) 687 2400</tt>.
            If the phone number contains an extension, it is RECOMMENDED that
            the extension be represented using the
            <a class="info" href="#RFC3966">RFC
                3966<span> (</span><span class="info">Schulzrinne, H., “The tel URI for Telephone Numbers,” December&nbsp;2004.</span><span>)</span></a>
            [RFC3966] extension syntax,
            for example, <tt>+1 (604) 555-1234;ext=5678</tt>.
        </td>
    </tr>
    <tr>
        <td align="left">phone_number_verified</td>
        <td align="left">boolean</td>
        <td align="left">
            True if the End-User's phone number has been verified; otherwise false.
            When this Claim Value is <tt>true</tt>,
            this means that the OP took affirmative steps
            to ensure that this phone number was controlled by the End-User
            at the time the verification was performed.
            The means by which a phone number is verified is context-specific,
            and dependent upon the trust framework or contractual agreements
            within which the parties are operating.
            When true, the <tt>phone_number</tt>
            Claim MUST be in E.164 format
            and any extensions MUST be represented in RFC 3966 format.
        </td>
    </tr>
    <tr>
        <td align="left">address</td>
        <td align="left">JSON object</td>
        <td align="left">
            End-User's preferred postal address.
            The value of the <tt>address</tt> member is
            a JSON <a class="info"
                      href="#RFC4627">[RFC4627]<span> (</span><span
                class="info">Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July&nbsp;2006.</span><span>)</span></a>
            structure containing some or all of
            the members defined in <a class="info"
                                      href="#AddressClaim">Section&nbsp;5.1.1<span> (</span><span
                class="info">Address Claim</span><span>)</span></a>.
        </td>
    </tr>
    <tr>
        <td align="left">updated_at</td>
        <td align="left">number</td>
        <td align="left">
            Time the End-User's information was last updated.
            Its value is a JSON number representing the number of seconds from
            1970-01-01T0:0:0Z as measured in UTC until the date/time.
        </td>
    </tr>
    </tbody>
</table>
<br clear="all">
<table border="0" cellpadding="0" cellspacing="2" align="center">
    <tbody>
    <tr>
        <td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 1: Registered Member Definitions&nbsp;</b></font><br>
        </td>
    </tr>
    </tbody>
</table>
<hr class="insert">

<a name="AddressClaim"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.1.1"></a>

<h3>5.1.1.&nbsp;
    Address Claim</h3>

<p>
    The Address Claim represents a physical mailing address.
    Implementations MAY return only a subset of the
    fields of an <tt>address</tt>, depending upon
    the information available and the End-User's privacy
    preferences. For
    example, the <tt>country</tt> and <tt>region</tt> might be returned without returning
    more fine-grained address information.

</p>

<p>
    Implementations MAY return just the full address
    as a single string in the formatted sub-field,
    or they MAY return just the individual component
    fields using the other sub-fields,
    or they MAY return both.
    If both variants are returned,
    they SHOULD be describing the same address,
    with the formatted address indicating how the
    component fields are combined.

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>formatted</dt>
        <dd>

            Full mailing address,
            formatted for display or use on a mailing label.
            This field MAY contain multiple lines, separated by newlines.
            Newlines can be represented either as
            a carriage return/line feed pair ("\r\n") or as
            a single line feed character ("\n").

        </dd>
        <dt>street_address</dt>
        <dd>

            Full street address component,
            which MAY include house number, street name,
            Post Office Box, and multi-line extended street
            address information.
            This field MAY contain multiple lines, separated by newlines.
            Newlines can be represented either as
            a carriage return/line feed pair ("\r\n") or as
            a single line feed character ("\n").

        </dd>
        <dt>locality</dt>
        <dd>

            City or locality component.

        </dd>
        <dt>region</dt>
        <dd>

            State, province,
            prefecture, or region component.

        </dd>
        <dt>postal_code</dt>
        <dd>

            Zip code or
            postal code component.

        </dd>
        <dt>country</dt>
        <dd>

            Country name component.

        </dd>
    </dl>
</blockquote>
<p>

</p>
<a name="AdditionalClaims"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.1.2"></a>

<h3>5.1.2.&nbsp;
    Additional Claims</h3>

<p>
    While this specification defines only a small set of Claims as
    standard Claims, other Claims MAY be used in conjunction
    with the standard Claims.
    When using such Claims, it is RECOMMENDED that
    collision-resistant names be used for the Claim Names,
    as described in the
    <a class="info" href="#JWT">JSON Web Token
        (JWT)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>
    [JWT] specification.
    Alternatively, Private Claim Names can be safely used
    when naming conflicts are unlikely to arise,
    as described in the JWT specification.
    Or, if specific additional Claims will have broad and general applicability,
    they can be registered with Registered Claim Names,
    per the JWT specification.

</p>
<a name="ClaimsLanguagesAndScripts"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.2"></a>

<h3>5.2.&nbsp;
    Claims Languages and Scripts</h3>

<p>
    Human-readable Claim Values and Claim Values that reference human-readable values
    MAY be represented in multiple languages and scripts.
    To specify the languages and scripts, <a class="info"
                                             href="#RFC5646">BCP47<span> (</span><span
        class="info">Phillips, A. and M. Davis, “Tags for Identifying Languages,” September&nbsp;2009.</span><span>)</span></a>
    [RFC5646] language tags are added to member names,
    delimited by a <tt>#</tt> character. For example,
    <tt>family_name#ja-Kana-JP</tt> expresses the
    Family Name in Katakana in Japanese, which is commonly used to index
    and represent the phonetics of the Kanji representation of the same
    represented as <tt>family_name#ja-Hani-JP</tt>.
    As another example, both <tt>website</tt> and
    <tt>website#de</tt> Claim Values might be returned,
    referencing a Web site in an unspecified language and a Web site
    in German.

</p>

<p>
    Since Claim Names are case sensitive, it is strongly RECOMMENDED
    that language tag values used in Claim Names be spelled using the
    character case with which they are registered in the
    <a class="info" href="#IANA.Language">IANA Language Subtag
        Registry<span> (</span><span class="info">Internet Assigned Numbers Authority (IANA), “Language Subtag Registry,” 2005.</span><span>)</span></a>
    [IANA.Language].
    In particular, normally language names are spelled with lowercase characters,
    region names are spelled with uppercase characters, and
    scripts are spelled with mixed case characters.
    However, since BCP47 language tag values are case insensitive,
    implementations SHOULD interpret the language tag values supplied
    in a case insensitive manner.

</p>

<p>
    Per the recommendations in BCP47, language tag values for Claims
    SHOULD only be as specific as necessary.
    For instance, using <tt>fr</tt> might be sufficient
    in many contexts, rather than <tt>fr-CA</tt> or
    <tt>fr-FR</tt>.
    Where possible, OPs SHOULD try to match requested Claim locales with
    Claims it has. For instance, if the Client asks for a Claim with
    a <tt>de</tt> (German) language tag and the OP
    has a value tagged with <tt>de-CH</tt> (Swiss German)
    and no generic German value, it would be appropriate for the OP
    to return the Swiss German value to the Client.
    (This intentionally moves as much of the complexity of language tag
    matching to the OP as possible, to simplify Clients.)

</p>

<p>
    OpenID Connect defines the following Authorization Request parameter
    to enable specify the preferred languages and scripts to be used
    for the returned Claims:

</p>
<blockquote class="text">
    <dl>
        <dt>claims_locales</dt>
        <dd>

            OPTIONAL.
            End-User's preferred languages and scripts for Claims being returned,
            represented as a space-separated list of
            <a class="info"
               href="#RFC5646">BCP47<span> (</span><span
                    class="info">Phillips, A. and M. Davis, “Tags for Identifying Languages,” September&nbsp;2009.</span><span>)</span></a>
            [RFC5646] language tag values,
            ordered by preference.
            An error SHOULD NOT result if some or all of the requested locales
            are not supported by the OpenID Provider.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    When the OP determines, either through the
    <tt>claims_locales</tt> parameter,
    or by other means, that the End-User and Client are
    requesting Claims in only one set of languages and scripts,
    it is RECOMMENDED that OPs return Claims without language tags
    when they employ this language and script.
    It is also RECOMMENDED that Clients be written in a manner
    that they can handle and utilize Claims using language tags.

</p>
<a name="UserInfo"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.3"></a>

<h3>5.3.&nbsp;
    UserInfo Endpoint</h3>

<p>
    The UserInfo Endpoint is an OAuth 2.0 Protected Resource that
    returns Claims about the authenticated End-User.
    To obtain the requested Claims about the End-User, the Client
    makes a request to the UserInfo Endpoint
    using an Access Token obtained through OpenID Connect Authentication.
    These Claims are normally represented by a JSON object that contains
    a collection of name and value pairs for the Claims.

</p>

<p>
    Communication with the UserInfo Endpoint MUST utilize TLS.
    See <a class="info"
           href="#TLSRequirements">Section&nbsp;16.17<span> (</span><span
        class="info">TLS Requirements</span><span>)</span></a> for more information on using TLS.

</p>

<p>
    The UserInfo Endpoint MUST support the use of the
    HTTP <tt>GET</tt> and
    HTTP <tt>POST</tt> methods
    defined in <a class="info" href="#RFC2616">RFC
    2616<span> (</span><span class="info">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June&nbsp;1999.</span><span>)</span></a>
    [RFC2616].

</p>

<p>The UserInfo Endpoint MUST accept Access Tokens as
    <a class="info" href="#RFC6750">OAuth 2.0 Bearer Token
        Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6750].
</p>

<p>The UserInfo Endpoint SHOULD support the use of
    <a class="info" href="#CORS">Cross Origin Resource Sharing
        (CORS)<span> (</span><span
                class="info">Opera Software ASA, “Cross-Origin Resource Sharing,” July&nbsp;2010.</span><span>)</span></a>
    [CORS] and
    or other methods as appropriate to enable Java Script Clients to access the endpoint.
</p>
<a name="UserInfoRequest"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.3.1"></a>

<h3>5.3.1.&nbsp;
    UserInfo Request</h3>

<p>
    The Client sends the UserInfo Request using either
    HTTP <tt>GET</tt> or HTTP <tt>POST</tt>.
    The Access Token obtained
    from an OpenID Connect Authentication Request MUST be sent as a Bearer Token,
    per Section 2 of <a class="info" href="#RFC6750">OAuth 2.0
    Bearer Token Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6750].

</p>

<p>
    It is RECOMMENDED that the request use the
    HTTP <tt>GET</tt> method and
    the Access Token be sent using the
    <tt>Authorization</tt> header field.

</p>

<p>
    The following is a non-normative example of a UserInfo Request:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /userinfo HTTP/1.1
  Host: server.example.com
  Authorization: Bearer SlAV32hkKG
</pre>
</div>
<a name="UserInfoResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.3.2"></a>

<h3>5.3.2.&nbsp;
    Successful UserInfo Response</h3>

<p>
    The UserInfo Claims MUST be returned as the members of a JSON object
    unless a signed or encrypted response was requested during Client Registration.
    The Claims defined in <a class="info" href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
        class="info">Standard Claims</span><span>)</span></a> can be returned,
    as can additional Claims not specified there.

</p>

<p>
    For privacy reasons, OpenID Providers MAY elect to not return
    values for some requested Claims.

</p>

<p>
    If a Claim is not returned, that Claim Name SHOULD be
    omitted from the JSON object representing the Claims; it
    SHOULD NOT be present with a null or empty string value.

</p>

<p>
    The <tt>sub</tt> (subject) Claim
    MUST always be returned in the UserInfo Response.

</p>

<p>
    NOTE: Due to the possibility of token substitution attacks
    (see <a class="info" href="#TokenSubstitution">Section&nbsp;16.11<span> (</span><span
        class="info">Token Substitution</span><span>)</span></a>),
    the UserInfo Response is not guaranteed to be about the
    End-User identified by the <tt>sub</tt> (subject)
    element of the ID Token.
    The <tt>sub</tt> Claim in the UserInfo Response
    MUST be verified to exactly match the
    <tt>sub</tt> Claim in the ID Token;
    if they do not match, the UserInfo Response values MUST NOT be used.

</p>

<p>
    Upon receipt of the UserInfo Request, the UserInfo Endpoint MUST
    return the JSON Serialization of the UserInfo Response as in
    <a class="info"
       href="#JSONSerialization">Section&nbsp;13.3<span> (</span><span
            class="info">JSON Serialization</span><span>)</span></a> in the HTTP response
    body unless a
    different format was specified during Registration
    <a class="info" href="#OpenID.Registration">[OpenID.Registration]<span> (</span><span
            class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November&nbsp;2014.</span><span>)</span></a>.
    The UserInfo Endpoint MUST return a content-type header to indicate
    which format is being returned.
    The content-type of the HTTP response MUST be <tt>application/json</tt> if the response body is a text
    JSON object;
    the response body SHOULD be encoded using UTF-8.

</p>

<p>
    If the UserInfo Response is
    signed and/or encrypted, then the Claims are returned in a JWT and the
    content-type MUST be <tt>application/jwt</tt>.
    The response MAY be encrypted without also being signed.
    If both signing and encryption are requested,
    the response MUST be signed then encrypted,
    with the result being a Nested JWT, as defined in <a class="info"
                                                         href="#JWT">[JWT]<span> (</span><span
        class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>.

</p>

<p>
    If signed, the UserInfo Response
    SHOULD contain the Claims
    <tt>iss</tt> (issuer)
    and <tt>aud</tt> (audience) as members.
    The <tt>iss</tt> value SHOULD be the OP's Issuer Identifier URL.
    The <tt>aud</tt> value SHOULD be or include the RP's Client ID value.

</p>

<p>The following is a non-normative example
    of a UserInfo Response:
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 200 OK
  Content-Type: application/json

  {
   "sub": "248289761001",
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "preferred_username": "j.doe",
   "email": "janedoe@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }
</pre>
</div>
<a name="UserInfoError"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.3.3"></a>

<h3>5.3.3.&nbsp;
    UserInfo Error Response</h3>

<p>
    When an error condition occurs, the UserInfo Endpoint returns
    an Error Response as defined in Section 3 of
    <a class="info" href="#RFC6750">OAuth 2.0 Bearer Token
        Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6750].
    (HTTP errors unrelated to RFC 6750 are returned to the User Agent using the
    appropriate HTTP status code.)

</p>

<p>The following is a non-normative example
    of a UserInfo Error Response:
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: error="invalid_token",
    error_description="The Access Token expired"
</pre>
</div>
<a name="UserInfoResponseValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.3.4"></a>

<h3>5.3.4.&nbsp;
    UserInfo Response Validation</h3>

<p>
    The Client MUST validate the UserInfo Response as follows:

</p>

<p>
</p>
<ol class="text">
    <li>Verify that the OP that responded was the intended OP
        through a TLS server certificate check, per
        <a class="info" href="#RFC6125">RFC 6125<span> (</span><span
                class="info">Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March&nbsp;2011.</span><span>)</span></a>
        [RFC6125].
    </li>
    <li>If the Client has provided a
        <tt>userinfo_encrypted_response_alg</tt>
        parameter during Registration, decrypt the UserInfo Response
        using the keys specified during Registration.
    </li>
    <li>If the response was signed, the Client SHOULD validate the
        signature according to <a class="info" href="#JWS">JWS<span> (</span><span
                class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>
        [JWS].
    </li>
</ol>
<p>

</p>
<a name="ScopeClaims"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.4"></a>

<h3>5.4.&nbsp;
    Requesting Claims using Scope Values</h3>

<p>
    OpenID Connect Clients use <tt>scope</tt> values,
    as defined in Section 3.3 of <a class="info" href="#RFC6749">OAuth
    2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749],
    to specify what
    access privileges are being requested for Access Tokens. The scopes associated
    with Access Tokens determine what resources will be available when they are
    used to access OAuth 2.0 protected endpoints.
    Protected Resource endpoints MAY perform different actions and
    return different information based on the scope values and other parameters
    used when requesting the presented Access Token.

</p>

<p>
    For OpenID Connect, scopes
    can be used to request that specific sets of information
    be made available as Claim Values.

</p>

<p>
    Claims requested by the following scopes are treated by Authorization Servers
    as Voluntary Claims.

</p>

<p>
    OpenID Connect defines the following <tt>scope</tt> values
    that are used to request Claims:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>profile</dt>
        <dd>

            OPTIONAL. This scope value
            requests access to the End-User's default profile Claims,
            which are:

            <tt>name</tt>,
            <tt>family_name</tt>,
            <tt>given_name</tt>,
            <tt>middle_name</tt>,
            <tt>nickname</tt>,
            <tt>preferred_username</tt>,
            <tt>profile</tt>,
            <tt>picture</tt>,
            <tt>website</tt>,
            <tt>gender</tt>,
            <tt>birthdate</tt>,
            <tt>zoneinfo</tt>,
            <tt>locale</tt>, and
            <tt>updated_at</tt>.

        </dd>
        <dt>email</dt>
        <dd>

            OPTIONAL. This scope value requests access to
            the <tt>email</tt> and
            <tt>email_verified</tt> Claims.

        </dd>
        <dt>address</dt>
        <dd>

            OPTIONAL. This scope value requests access to
            the <tt>address</tt> Claim.

        </dd>
        <dt>phone</dt>
        <dd>

            OPTIONAL. This scope value requests access to
            the <tt>phone_number</tt> and
            <tt>phone_number_verified</tt> Claims.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>Multiple scope values MAY be used by creating a space delimited, case
    sensitive list of ASCII scope values.
</p>

<p>
    The Claims requested by the
    <tt>profile</tt>,
    <tt>email</tt>,
    <tt>address</tt>, and
    <tt>phone</tt> scope values
    are returned from the UserInfo Endpoint,
    as described in <a class="info" href="#UserInfoResponse">Section&nbsp;5.3.2<span> (</span><span
        class="info">Successful UserInfo Response</span><span>)</span></a>,
    when a <tt>response_type</tt> value is used
    that results in an Access Token being issued.
    However, when no Access Token is issued
    (which is the case for the <tt>response_type</tt>
    value <tt>id_token</tt>),
    the resulting Claims are returned in the ID Token.

</p>

<p>In some cases, the End-User will be given the option to
    have the OpenID Provider decline to provide some or all
    information requested by RPs.
    To minimize the amount of information that the End-User is being asked
    to disclose, an RP can elect to
    only request a subset of the information available from the
    UserInfo Endpoint.
</p>

<p>

</p>

<p>
    The following is a non-normative example of an unencoded
    <tt>scope</tt> request:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  scope=openid profile email phone
</pre>
</div>


<a name="ClaimsParameter"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.5"></a>

<h3>5.5.&nbsp;
    Requesting Claims using the "claims" Request Parameter</h3>

<p>
    OpenID Connect defines the following Authorization Request parameter
    to enable requesting individual Claims
    and specifying parameters that apply to the requested Claims:

</p>
<blockquote class="text">
    <dl>
        <dt>claims</dt>
        <dd>

            OPTIONAL.
            This parameter is used to request that specific Claims be returned.
            The value is a JSON object listing the requested Claims.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    The <tt>claims</tt> Authentication Request
    parameter requests that specific Claims
    be returned from the UserInfo Endpoint and/or in the ID Token.
    It is represented as a JSON object containing lists of Claims being requested
    from these locations.
    Properties of the Claims being requested MAY also be specified.

</p>

<p>
    Support for the <tt>claims</tt> parameter is OPTIONAL.
    Should an OP not support this parameter and an RP uses it,
    the OP SHOULD return a set of Claims to the RP that it believes would
    be useful to the RP and the End-User using whatever heuristics it
    believes are appropriate.
    The <tt>claims_parameter_supported</tt>
    Discovery result indicates whether the OP supports this parameter.

</p>

<p>
    The <tt>claims</tt> parameter value is represented
    in an OAuth 2.0 request as UTF-8 encoded JSON
    (which ends up being form-urlencoded when passed as an OAuth parameter).
    When used in a Request Object value, per <a class="info"
                                                href="#RequestObject">Section&nbsp;6.1<span> (</span><span
        class="info">Passing a Request Object by Value</span><span>)</span></a>,
    the JSON is used as the value of the
    <tt>claims</tt> member.

</p>

<p>
    The top-level members of the Claims request JSON object are:

</p>
<blockquote class="text">
    <dl>
        <dt>userinfo</dt>
        <dd>

            OPTIONAL.
            Requests that the listed individual Claims be returned
            from the UserInfo Endpoint.
            If present, the listed Claims are being requested to be added to
            any Claims that are being requested using
            <tt>scope</tt> values.
            If not present, the Claims being requested from the UserInfo Endpoint
            are only those requested using <tt>scope</tt> values.

        </dd>
        <dt></dt>
        <dd>
            When the <tt>userinfo</tt> member is used,
            the request MUST also use a <tt>response_type</tt>
            value that results in an Access Token being issued to the Client
            for use at the UserInfo Endpoint.

        </dd>
        <dt>id_token</dt>
        <dd>

            OPTIONAL.
            Requests that the listed individual Claims be returned
            in the ID Token.
            If present, the listed Claims are being requested to be added to
            the default Claims in the ID Token.
            If not present, the default ID Token Claims are requested,
            as per the ID Token definition in <a class="info"
                                                 href="#IDToken">Section&nbsp;2<span> (</span><span
                class="info">ID Token</span><span>)</span></a>
            and per the additional per-flow ID Token requirements in Sections
            <a class="info"
               href="#CodeIDToken">3.1.3.6<span> (</span><span
                    class="info">ID Token</span><span>)</span></a>,
            <a class="info"
               href="#ImplicitIDToken">3.2.2.10<span> (</span><span
                    class="info">ID Token</span><span>)</span></a>,
            <a class="info"
               href="#HybridIDToken">3.3.2.11<span> (</span><span
                    class="info">ID Token</span><span>)</span></a>,
            and <a class="info" href="#HybridIDToken2">3.3.3.6<span> (</span><span
                class="info">ID Token</span><span>)</span></a>.

        </dd>
    </dl>
</blockquote>
<p>

    Other members MAY be present.
    Any members used that are not understood MUST be ignored.

</p>

<p>

</p>

<p>An example Claims request is as follows:
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "userinfo":
    {
     "given_name": {"essential": true},
     "nickname": null,
     "email": {"essential": true},
     "email_verified": {"essential": true},
     "picture": null,
     "http://example.info/claims/groups": null
    },
   "id_token":
    {
     "auth_time": {"essential": true},
     "acr": {"values": ["urn:mace:incommon:iap:silver"] }
    }
  }
</pre>
</div>
Note that a Claim that is not in the standard set defined in
<a class="info"
   href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
        class="info">Standard Claims</span><span>)</span></a>, the (example)
<tt>http://example.info/claims/groups</tt> Claim,
is being requested.
Using the <tt>claims</tt> parameter is the only
way to request Claims outside the standard set.
It is also the only way to request specific combinations of the
standard Claims that cannot be specified using scope values.


<a name="IndividualClaimsRequests"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.5.1"></a>

<h3>5.5.1.&nbsp;
    Individual Claims Requests</h3>

<p>
    The <tt>userinfo</tt> and
    <tt>id_token</tt> members of the
    <tt>claims</tt> request both are JSON objects
    with the names of the individual Claims being requested as the member names.
    The member values MUST be one of the following:

</p>
<blockquote class="text">
    <dl>
        <dt>null</dt>
        <dd>

            Indicates that this Claim is being requested in the default manner.
            In particular, this is a Voluntary Claim.
            For instance, the Claim request:

            <div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  "given_name": null
</pre>
            </div>

            requests the <tt>given_name</tt> Claim
            in the default manner.

        </dd>
        <dt>JSON Object</dt>
        <dd>

            Used to provide additional information about the Claim being
            requested. This specification defines the following members:


            <blockquote class="text">
                <dl>
                    <dt>essential</dt>
                    <dd>

                        OPTIONAL.
                        Indicates whether the Claim being requested is an Essential Claim.
                        If the value is <tt>true</tt>,
                        this indicates that the Claim is an Essential Claim.
                        For instance, the Claim request:

                        <div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  "auth_time": {"essential": true}
</pre>
                        </div>

                        can be used to specify that it is Essential to return an
                        <tt>auth_time</tt> Claim Value.

                    </dd>
                    <dt></dt>
                    <dd>
                        If the value is <tt>false</tt>,
                        it indicates that it is a Voluntary Claim.
                        The default is <tt>false</tt>.

                    </dd>
                    <dt></dt>
                    <dd>
                        By requesting Claims as Essential Claims,
                        the RP indicates to the End-User
                        that releasing these Claims will ensure a smooth authorization
                        for the specific task requested by the End-User.
                        Note that even if the Claims are not available because
                        the End-User did not authorize their release or they are not present,
                        the Authorization Server MUST NOT generate an error when
                        Claims are not returned, whether they are Essential or Voluntary,
                        unless otherwise specified in the description of the specific claim.

                    </dd>
                    <dt>value</dt>
                    <dd>

                        OPTIONAL.
                        Requests that the Claim be returned with a particular value.
                        For instance the Claim request:

                        <div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  "sub": {"value": "248289761001"}
</pre>
                        </div>

                        can be used to specify that the request apply to the End-User
                        with Subject Identifier <tt>248289761001</tt>.

                    </dd>
                    <dt></dt>
                    <dd>
                        The value of the <tt>value</tt> member
                        MUST be a valid value for the Claim being requested.
                        Definitions of individual Claims can include requirements on
                        how and whether the <tt>value</tt>
                        qualifier is to be used when requesting that Claim.

                    </dd>
                    <dt>values</dt>
                    <dd>

                        OPTIONAL.
                        Requests that the Claim be returned with one of a set of values,
                        with the values appearing in order of preference.
                        For instance the Claim request:

                        <div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  "acr": {"essential": true,
          "values": ["urn:mace:incommon:iap:silver",
                     "urn:mace:incommon:iap:bronze"]}
</pre>
                        </div>

                        specifies that it is Essential that the <tt>acr</tt>
                        Claim be returned with either the value
                        <tt>urn:mace:incommon:iap:silver</tt> or
                        <tt>urn:mace:incommon:iap:bronze</tt>.

                    </dd>
                    <dt></dt>
                    <dd>
                        The values in the <tt>values</tt> member array
                        MUST be valid values for the Claim being requested.
                        Definitions of individual Claims can include requirements on
                        how and whether the <tt>values</tt>
                        qualifier is to be used when requesting that Claim.

                    </dd>
                </dl>
            </blockquote>

            Other members MAY be defined to provide additional
            information about the requested Claims.
            Any members used that are not understood MUST be ignored.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    Note that when the <tt>claims</tt> request parameter
    is supported, the scope values that request Claims, as defined in
    <a class="info"
       href="#ScopeClaims">Section&nbsp;5.4<span> (</span><span
            class="info">Requesting Claims using Scope Values</span><span>)</span></a>, are effectively shorthand
    methods for
    requesting sets of individual Claims.
    For example, using the scope value <tt>openid email</tt>
    and a <tt>response_type</tt> that returns an Access Token
    is equivalent to using the scope value <tt>openid</tt>
    and the following request for individual Claims.


</p>

<p>
    Equivalent of using the <tt>email</tt> scope value:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "userinfo":
    {
     "email": null,
     "email_verified": null
    }
  }
</pre>
</div>


<a name="acrSemantics"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.5.1.1"></a>

<h3>5.5.1.1.&nbsp;
    Requesting the "acr" Claim</h3>

<p>
    If the <tt>acr</tt> Claim is requested
    as an Essential Claim for the ID Token
    with a <tt>values</tt> parameter requesting
    specific Authentication Context Class Reference values and
    the implementation supports the <tt>claims</tt> parameter,
    the Authorization Server MUST return an <tt>acr</tt>
    Claim Value that matches one of the requested values.
    The Authorization Server MAY ask the End-User to re-authenticate
    with additional factors
    to meet this requirement. If this is an Essential Claim and the
    requirement cannot be met, then the Authorization Server MUST
    treat that outcome as a failed authentication attempt.

</p>

<p>
    Note that the RP MAY request the <tt>acr</tt>
    Claim as a Voluntary Claim
    by using the <tt>acr_values</tt> request parameter
    or by not including "essential": true in an individual
    <tt>acr</tt> Claim request.
    If the Claim is not Essential and a requested value
    cannot be provided, the Authorization Server SHOULD return
    the session's current <tt>acr</tt> as
    the value of the <tt>acr</tt> Claim.
    If the Claim is not Essential, the Authorization Server is not required to
    provide this Claim in its response.

</p>

<p>
    If the client requests the <tt>acr</tt> Claim using
    both the <tt>acr_values</tt> request parameter and
    an individual <tt>acr</tt> Claim request for the ID Token
    listing specific requested values,
    the resulting behavior is unspecified.

</p>
<a name="IndividualClaimsLanguages"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.5.2"></a>

<h3>5.5.2.&nbsp;
    Languages and Scripts for Individual Claims</h3>

<p>
    As described in <a class="info"
                       href="#ClaimsLanguagesAndScripts">Section&nbsp;5.2<span> (</span><span
        class="info">Claims Languages and Scripts</span><span>)</span></a>,
    human-readable Claim Values and Claim Values that reference human-readable values
    MAY be represented in multiple languages and scripts.
    Within a request for individual Claims, requested languages and scripts
    for particular Claims MAY be requested by including Claim Names
    that contain <tt>#</tt>-separated
    <a class="info" href="#RFC5646">BCP47<span> (</span><span
            class="info">Phillips, A. and M. Davis, “Tags for Identifying Languages,” September&nbsp;2009.</span><span>)</span></a>
    [RFC5646] language tags
    in the Claims request, using the Claim Name syntax specified in
    <a class="info" href="#ClaimsLanguagesAndScripts">Section&nbsp;5.2<span> (</span><span
            class="info">Claims Languages and Scripts</span><span>)</span></a>.
    For example, a Family Name in Katakana in Japanese
    can be requested using the Claim Name
    <tt>family_name#ja-Kana-JP</tt>
    and a Kanji representation of the Family Name in Japanese
    can be requested using the Claim Name
    <tt>family_name#ja-Hani-JP</tt>.
    A German-language Web site can be requested with the Claim Name
    <tt>website#de</tt>.

</p>

<p>
    If an OP receives a request for human-readable Claims in a language and script
    that it doesn't have, any versions of those Claims returned that don't use
    the requested language and script SHOULD use a language tag in the Claim Name.

</p>
<a name="ClaimTypes"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.6"></a>

<h3>5.6.&nbsp;
    Claim Types</h3>

<p>
    Three representations of Claim Values are defined by this specification:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>Normal Claims</dt>
        <dd>

            Claims that are directly asserted by
            the OpenID Provider.

        </dd>
        <dt>Aggregated Claims</dt>
        <dd>

            Claims that are asserted by a
            Claims Provider other than the OpenID Provider but are returned
            by OpenID Provider.

        </dd>
        <dt>Distributed Claims</dt>
        <dd>

            Claims that are asserted by a
            Claims Provider other than the OpenID Provider but are returned
            as references by the OpenID Provider.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    Normal Claims MUST be supported.
    Support for Aggregated Claims and Distributed Claims is OPTIONAL.

</p>
<a name="NormalClaims"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.6.1"></a>

<h3>5.6.1.&nbsp;
    Normal Claims</h3>

<p>Normal Claims are represented as members in a JSON object. The
    Claim Name is the member name and the Claim Value is the member
    value.
</p>

<p>The following is a non-normative response containing Normal Claims:
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "email": "janedoe@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }
</pre>
</div>
<a name="AggregatedDistributedClaims"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.6.2"></a>

<h3>5.6.2.&nbsp;
    Aggregated and Distributed Claims</h3>

<p>Aggregated and distributed Claims are represented by
    using special <tt>_claim_names</tt> and
    <tt>_claim_sources</tt> members
    of the JSON object containing the Claims.
</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>_claim_names</dt>
        <dd>

            JSON object whose member
            names are the Claim Names for the Aggregated and Distributed
            Claims. The member values are references to the member names
            in the <tt>_claim_sources</tt> member from which
            the actual Claim Values can be retrieved.

        </dd>
        <dt>_claim_sources</dt>
        <dd>

            JSON object whose
            member names are referenced by the member values of the
            <tt>_claim_names</tt> member. The member values
            contain sets of Aggregated Claims or reference locations for
            Distributed Claims. The member values can have one of the
            following formats depending on whether it is providing
            Aggregated or Distributed Claims:


            <blockquote class="text">
                <dl>
                    <dt>Aggregated Claims</dt>
                    <dd>

                        JSON object that MUST
                        contain the <tt>JWT</tt> member whose value is a <a class="info"
                                                                            href="#JWT">JWT<span> (</span><span
                            class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>
                        [JWT] that MUST contain all the Claims
                        in the <tt>_claim_names</tt> object that references the
                        corresponding <tt>_claim_sources</tt> member.
                        Other members MAY be present.
                        Any members used that are not understood MUST be ignored.


                        <blockquote class="text">
                            <dl>
                                <dt>JWT</dt>
                                <dd>

                                    REQUIRED.
                                    JWT containing Claim Values.

                                </dd>
                            </dl>
                        </blockquote>

                    </dd>
                    <dt></dt>
                    <dd>
                        The JWT SHOULD NOT contain a <tt>sub</tt> (subject)
                        Claim unless its value is an identifier for the End-User at
                        the Claims Provider (and not for the OpenID Provider or another party);
                        this typically means that a <tt>sub</tt> Claim
                        SHOULD NOT be provided.

                    </dd>
                    <dt>Distributed Claims</dt>
                    <dd>

                        JSON object that
                        contains the following members and values:


                        <blockquote class="text">
                            <dl>
                                <dt>endpoint</dt>
                                <dd>

                                    REQUIRED.
                                    OAuth 2.0 resource endpoint from which the associated
                                    Claim can be retrieved. The endpoint URL MUST return
                                    the Claim as a JWT.

                                </dd>
                                <dt>access_token</dt>
                                <dd>

                                    OPTIONAL.
                                    Access Token
                                    enabling retrieval of the Claims from the endpoint URL
                                    by using the <a class="info"
                                                    href="#RFC6750">OAuth
                                    2.0 Bearer Token Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October&nbsp;2012.</span><span>)</span></a>
                                    [RFC6750]
                                    protocol. Claims SHOULD be requested using
                                    the Authorization Request header field and Claims Providers
                                    MUST support this method. If the Access Token
                                    is not available, RPs MAY need to retrieve the
                                    Access Token out of band or use an Access Token
                                    that was pre-negotiated between the Claims Provider and
                                    RP, or the Claims Provider MAY reauthenticate the
                                    End-User and/or reauthorize the RP.

                                </dd>
                            </dl>
                        </blockquote>

                    </dd>
                    <dt></dt>
                    <dd>
                        A <tt>sub</tt> (subject) Claim SHOULD NOT
                        be returned from the Claims Provider
                        unless its value is an identifier for the End-User at
                        the Claims Provider (and not for the OpenID Provider or another party);
                        this typically means that a <tt>sub</tt> Claim
                        SHOULD NOT be provided.

                    </dd>
                </dl>
            </blockquote>

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    In general, it is up to the OP when it is appropriate to use
    Aggregated Claims and Distributed Claims.
    In some cases, information about when to use what Claim Types
    might be negotiated out of band between RPs and OPs.

</p>
<a name="AggregatedExample"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.6.2.1"></a>

<h3>5.6.2.1.&nbsp;
    Example of Aggregated Claims</h3>

<p>
    In this non-normative example, Claims from Claims Provider A
    are combined with other Claims held by the OpenID provider, with the
    Claims from Claims Provider A being returned as Aggregated Claims.

</p>

<p>

</p>

<p>
    In this example, these Claims about Jane Doe have been issued by
    Claims Provider A:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "address": {
     "street_address": "1234 Hollywood Blvd.",
     "locality": "Los Angeles",
     "region": "CA",
     "postal_code": "90210",
     "country": "US"},
   "phone_number": "+1 (310) 123-4567"
  }
</pre>
</div>


<p>
    Claims Provider A signs the JSON Claims, representing them in a signed JWT:
    jwt_header.jwt_part2.jwt_part3.
    It is this JWT that is used by the OpenID Provider.

</p>

<p>

</p>

<p>
    In this example, this JWT containing Jane Doe's Aggregated Claims
    from Claims Provider A is combined with other Normal Claims,
    and returned as the following set of Claims:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "birthdate": "0000-03-22",
   "eye_color": "blue",
   "email": "janedoe@example.com",
   "_claim_names": {
     "address": "src1",
     "phone_number": "src1"
   },
   "_claim_sources": {
     "src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}
   }
  }
</pre>
</div>


<a name="DistributedExample"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.6.2.2"></a>

<h3>5.6.2.2.&nbsp;
    Example of Distributed Claims</h3>

<p>
    In this non-normative example, the OpenID Provider combines
    Normal Claims that it holds with references to Claims held by
    two different Claims Providers, B and C, incorporating references
    to some of the Claims held by B and C as Distributed Claims.

</p>

<p>

</p>

<p>
    In this example, these Claims about Jane Doe are held by
    Claims Provider B (Jane Doe's bank):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "shipping_address": {
     "street_address": "1234 Hollywood Blvd.",
     "locality": "Los Angeles",
     "region": "CA",
     "postal_code": "90210",
     "country": "US"},
   "payment_info": "Some_Card 1234 5678 9012 3456",
   "phone_number": "+1 (310) 123-4567"
  }
</pre>
</div>


<p>

</p>

<p>
    Also in this example, this Claim about Jane Doe is held by
    Claims Provider C (a credit agency):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "credit_score": 650
  }
</pre>
</div>


<p>

</p>

<p>
    The OpenID Provider returns Jane Doe's Claims along with references
    to the Distributed Claims from Claims Provider B and Claims Provider C
    by sending the Access Tokens and URLs of locations from which the
    Distributed Claims can be retrieved:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "email": "janedoe@example.com",
   "birthdate": "0000-03-22",
   "eye_color": "blue",
   "_claim_names": {
     "payment_info": "src1",
     "shipping_address": "src1",
     "credit_score": "src2"
    },
   "_claim_sources": {
     "src1": {"endpoint":
                "https://bank.example.com/claim_source"},
     "src2": {"endpoint":
                "https://creditagency.example.com/claims_here",
              "access_token": "ksj3n283dke"}
   }
  }
</pre>
</div>


<a name="ClaimStability"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.5.7"></a>

<h3>5.7.&nbsp;
    Claim Stability and Uniqueness</h3>

<p>
    The <tt>sub</tt> (subject) and
    <tt>iss</tt> (issuer) Claims, used together,
    are the only Claims that an RP
    can rely upon as a stable identifier for the End-User,
    since the <tt>sub</tt>
    Claim MUST be locally unique and never reassigned within the Issuer
    for a particular End-User, as described in <a class="info"
                                                  href="#IDToken">Section&nbsp;2<span> (</span><span
        class="info">ID Token</span><span>)</span></a>.
    Therefore, the only guaranteed unique identifier for a given End-User is the
    combination of the <tt>iss</tt> Claim
    and the <tt>sub</tt> Claim.

</p>

<p>
    All other Claims carry no such guarantees across different issuers in terms of
    stability over time or uniqueness across users, and Issuers are permitted to
    apply local restrictions and policies. For instance, an Issuer MAY re-use an
    <tt>email</tt> Claim Value across different
    End-Users at different points in time, and the claimed
    <tt>email</tt> address for a given End-User MAY change
    over time.
    Therefore, other Claims such as <tt>email</tt>,
    <tt>phone_number</tt>, and
    <tt>preferred_username</tt>
    and MUST NOT be used as unique identifiers for the End-User.

</p>
<a name="JWTRequests"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6"></a>

<h3>6.&nbsp;
    Passing Request Parameters as JWTs</h3>

<p>
    OpenID Connect defines the following Authorization Request parameters
    to enable Authentication Requests to be signed and optionally encrypted:

</p>
<blockquote class="text">
    <dl>
        <dt>request</dt>
        <dd>

            OPTIONAL.
            This parameter enables
            OpenID Connect requests to be passed in a single,
            self-contained parameter and to be optionally signed and/or encrypted.
            The parameter value is a Request Object value,
            as specified in <a class="info" href="#RequestObject">Section&nbsp;6.1<span> (</span><span
                class="info">Passing a Request Object by Value</span><span>)</span></a>.
            It represents the request as a JWT whose Claims
            are the request parameters.

        </dd>
        <dt>request_uri</dt>
        <dd>

            OPTIONAL.
            This parameter enables
            OpenID Connect requests to be passed by reference, rather than by value.
            The <tt>request_uri</tt> value is a URL
            using the <tt>https</tt> scheme
            referencing a resource containing a Request Object value,
            which is a JWT containing the request parameters.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    Requests using these parameters are represented as JWTs, which are respectively
    passed by value or by reference.
    The ability to pass requests by reference is particularly useful for large requests.
    If one of these parameters is used,
    the other MUST NOT be used in the same request.

</p>
<a name="RequestObject"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.1"></a>

<h3>6.1.&nbsp;
    Passing a Request Object by Value</h3>

<p>
    The <tt>request</tt> Authorization Request parameter
    enables OpenID Connect requests to be passed in a single,
    self-contained parameter and to be optionally signed and/or encrypted.
    It represents the request as a JWT whose Claims are the request parameters
    specified in <a class="info" href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
        class="info">Authorization Endpoint</span><span>)</span></a>.
    This JWT is called a Request Object.

</p>

<p>
    Support for the <tt>request</tt> parameter is OPTIONAL.
    The <tt>request_parameter_supported</tt>
    Discovery result indicates whether the OP supports this parameter.
    Should an OP not support this parameter and an RP uses it,
    the OP MUST return the <tt>request_not_supported</tt>
    error.

</p>

<p>
    When the <tt>request</tt> parameter is used,
    the OpenID Connect request parameter values contained in the JWT
    supersede those passed using the OAuth 2.0 request syntax.
    However, parameters MAY also be passed using the OAuth 2.0 request syntax
    even when a Request Object is used;
    this would typically be done to enable a cached,
    pre-signed (and possibly pre-encrypted) Request Object value
    to be used containing the fixed request parameters, while parameters that
    can vary with each request, such as <tt>state</tt> and
    <tt>nonce</tt>, are passed as OAuth 2.0 parameters.

</p>

<p>
    So that the request is a valid OAuth 2.0 Authorization Request,
    values for the <tt>response_type</tt> and
    <tt>client_id</tt> parameters MUST be included
    using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0.
    The values for these parameters MUST match those in the Request Object,
    if present.

</p>

<p>
    Even if a <tt>scope</tt> parameter
    is present in the Request Object value,
    a <tt>scope</tt> parameter MUST always be passed using
    the OAuth 2.0 request syntax containing the
    <tt>openid</tt> scope value to indicate to the
    underlying OAuth 2.0 logic that this is an OpenID Connect request.

</p>

<p>
    The Request Object MAY be signed or unsigned (plaintext).
    When it is plaintext, this is indicated by use of the
    <tt>none</tt> algorithm <a class="info" href="#JWA">[JWA]<span> (</span><span
        class="info">Jones, M., “JSON Web Algorithms (JWA),” July&nbsp;2014.</span><span>)</span></a>
    in the JOSE Header. If signed, the Request Object
    SHOULD contain the Claims
    <tt>iss</tt> (issuer)
    and <tt>aud</tt> (audience) as members.
    The <tt>iss</tt> value SHOULD be the Client ID of the RP,
    unless it was signed by a different party than the RP.
    The <tt>aud</tt> value SHOULD be or include
    the OP's Issuer Identifier URL.

</p>

<p>
    The Request Object MAY also be encrypted using <a class="info"
                                                      href="#JWE">JWE<span> (</span><span
        class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July&nbsp;2014.</span><span>)</span></a>
    [JWE]
    and MAY be encrypted without also being signed.
    If both signing and encryption are performed, it MUST be signed then encrypted,
    with the result being a Nested JWT, as defined in <a class="info"
                                                         href="#JWT">[JWT]<span> (</span><span
        class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>.

</p>

<p>
    <tt>request</tt> and
    <tt>request_uri</tt> parameters
    MUST NOT be included in Request Objects.

</p>

<p>

</p>

<p>
    The following is a non-normative example of the Claims in
    a Request Object before base64url encoding and signing:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "iss": "s6BhdRkqt3",
   "aud": "https://server.example.com",
   "response_type": "code id_token",
   "client_id": "s6BhdRkqt3",
   "redirect_uri": "https://client.example.org/cb",
   "scope": "openid",
   "state": "af0ifjsldkj",
   "nonce": "n-0S6_WzA2Mj",
   "max_age": 86400,
   "claims":
    {
     "userinfo":
      {
       "given_name": {"essential": true},
       "nickname": null,
       "email": {"essential": true},
       "email_verified": {"essential": true},
       "picture": null
      },
     "id_token":
      {
       "gender": null,
       "birthdate": {"essential": true},
       "acr": {"values": ["urn:mace:incommon:iap:silver"]}
      }
    }
  }
</pre>
</div>

<p>
    Signing it with the <tt>RS256</tt> algorithm
    results in this Request Object value
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
  F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
  c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
  JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
  bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
  Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
  ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
  ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
  Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
  wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
  ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
  sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
  dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
  luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
  F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
  KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
  0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
  ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
  iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
</pre>
</div>

<p>
    The following RSA public key, represented in JWK format, can be used to
    validate the Request Object signature in this
    and subsequent Request Object examples
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "kty":"RSA",
   "kid":"k2bdc",
   "n":"y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE5P
        7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF
        I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa
        ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR
        adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV
        W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw",
   "e":"AQAB"
  }
</pre>
</div>


<a name="RequestParameter"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.1.1"></a>

<h3>6.1.1.&nbsp;
    Request using the "request" Request Parameter</h3>

<p>The Client sends the Authorization Request to the
    Authorization Endpoint.
</p>

<p>

</p>

<p>The following is a non-normative example of an
    Authorization Request using the <tt>request</tt>
    parameter
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  https://server.example.com/authorize?
    response_type=code%20id_token
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &amp;scope=openid
    &amp;state=af0ifjsldkj
    &amp;nonce=n-0S6_WzA2Mj
    &amp;request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA
    iczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmN
    vbSIsDQogInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWV
    udF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8
    vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiA
    ic3RhdGUiOiAiYWYwaWZqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWo
    iLA0KICJtYXhfYWdlIjogODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXN
    lcmluZm8iOiANCiAgICB7DQogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWw
    iOiB0cnVlfSwNCiAgICAgIm5pY2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjo
    geyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJ
    lc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgInBpY3R1cmUiOiBudWxsDQogICAgfSw
    NCiAgICJpZF90b2tlbiI6IA0KICAgIHsNCiAgICAgImdlbmRlciI6IG51bGwsDQo
    gICAgICJiaXJ0aGRhdGUiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAiYWN
    yIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOmluY29tbW9uOmlhcDpzaWx2ZXIiXX0
    NCiAgICB9DQogIH0NCn0.nwwnNsk1-ZkbmnvsF6zTHm8CHERFMGQPhos-EJcaH4H
    h-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyFKzuMXZFSZ3p6Mb8dkxtVyjoy2
    GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx0GxFbuPbj96tVuj11pTnmFC
    UR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8Kol-cSLWoYE9l5QqholImz
    jT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPGiyon_-Te111V8uE83Il
    zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
</pre>
</div>


<a name="RequestUriParameter"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.2"></a>

<h3>6.2.&nbsp;
    Passing a Request Object by Reference</h3>

<p>
    The <tt>request_uri</tt> Authorization Request parameter enables
    OpenID Connect requests to be passed by reference, rather than by value.
    This parameter is used identically to the
    <tt>request</tt> parameter, other than that
    the Request Object value is retrieved from the resource at the specified URL,
    rather than passed by value.

</p>

<p>
    The <tt>request_uri_parameter_supported</tt>
    Discovery result indicates whether the OP supports this parameter.
    Should an OP not support this parameter and an RP uses it,
    the OP MUST return the <tt>request_uri_not_supported</tt>
    error.

</p>

<p>
    When the <tt>request_uri</tt> parameter is used,
    the OpenID Connect request parameter values contained in the referenced JWT
    supersede those passed using the OAuth 2.0 request syntax.
    However, parameters MAY also be passed using the OAuth 2.0 request syntax
    even when a <tt>request_uri</tt> is used;
    this would typically be done to enable a cached,
    pre-signed (and possibly pre-encrypted) Request Object value
    to be used containing the fixed request parameters, while parameters that
    can vary with each request, such as <tt>state</tt> and
    <tt>nonce</tt>, are passed as OAuth 2.0 parameters.

</p>

<p>
    So that the request is a valid OAuth 2.0 Authorization Request,
    values for the <tt>response_type</tt> and
    <tt>client_id</tt> parameters MUST be included
    using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0.
    The values for these parameters MUST match those in the Request Object,
    if present.

</p>

<p>
    Even if a <tt>scope</tt> parameter
    is present in the referenced Request Object,
    a <tt>scope</tt> parameter MUST always be passed using
    the OAuth 2.0 request syntax containing the
    <tt>openid</tt> scope value to indicate to the
    underlying OAuth 2.0 logic that this is an OpenID Connect request.

</p>

<p>
    Servers MAY cache the contents of the resources referenced by Request URIs.
    If the contents of the referenced resource could ever change,
    the URI SHOULD include the base64url encoded SHA-256 hash of the
    referenced resource contents as the fragment component of the URI.
    If the fragment value used for a URI changes, that signals the server
    that any cached value for that URI with the old fragment value
    is no longer valid.

</p>

<p>
    Note that Clients MAY pre-register
    <tt>request_uri</tt> values using the
    <tt>request_uris</tt> parameter defined in
    Section 2.1 of the
    <a class="info" href="#OpenID.Registration">OpenID Connect
        Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November&nbsp;2014.</span><span>)</span></a>
    [OpenID.Registration]
    specification.
    OPs can require that <tt>request_uri</tt> values used
    be pre-registered with the <tt>require_request_uri_registration</tt>
    discovery parameter.

</p>

<p>
    The entire Request URI MUST NOT exceed 512 ASCII characters.

</p>

<p>
    The contents of the resource referenced by the URL MUST be a Request Object.
    The scheme used in the
    <tt>request_uri</tt> value MUST be <tt>https</tt>,
    unless the target Request Object is signed in a way that is verifiable by the
    Authorization Server.
    The <tt>request_uri</tt> value MUST be reachable by the
    Authorization Server, and SHOULD be reachable by the Client.

</p>

<p>

</p>

<p>The following is a non-normative example of
    the contents of a Request Object resource that can be
    referenced by a <tt>request_uri</tt>
    (with line wraps within values for display purposes only):
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
  F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
  c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
  JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
  bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
  Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
  ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
  ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
  Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
  wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
  ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
  sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
  dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
  luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
  F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
  KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
  0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
  ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
  iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
</pre>
</div>


<a name="CreateRequestUri"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.2.1"></a>

<h3>6.2.1.&nbsp;
    URL Referencing the Request Object</h3>

<p>
    The Client stores the Request Object resource either
    locally or remotely at a URL the Server can access.
    This URL is the Request URI, <tt>request_uri</tt>.

</p>

<p>
    If the Request Object includes requested values for Claims,
    it MUST NOT be revealed to anybody but the Authorization Server.
    As such, the <tt>request_uri</tt> MUST have
    appropriate entropy for its lifetime.
    It is RECOMMENDED that it be removed
    if it is known that it will not be used again
    or after a reasonable timeout
    unless access control measures are taken.

</p>

<p>The following is a non-normative example
    of a Request URI value
    (with line wraps within values for display purposes only):
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  https://client.example.org/request.jwt#
    GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
</pre>
</div>
<a name="UseRequestUri"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.2.2"></a>

<h3>6.2.2.&nbsp;
    Request using the "request_uri" Request Parameter</h3>

<p>The Client sends the Authorization Request to the
    Authorization Endpoint.
</p>

<p>The following is a non-normative example
    of an Authorization Request using the <tt>request_uri</tt> parameter
    (with line wraps within values for display purposes only):
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  https://server.example.com/authorize?
    response_type=code%20id_token
    &amp;client_id=s6BhdRkqt3
    &amp;request_uri=https%3A%2F%2Fclient.example.org%2Frequest.jwt
    %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
    &amp;state=af0ifjsldkj&amp;nonce=n-0S6_WzA2Mj
    &amp;scope=openid
</pre>
</div>
<a name="GetRequestUri"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.2.3"></a>

<h3>6.2.3.&nbsp;
    Authorization Server Fetches Request Object</h3>

<p>Upon receipt of the Request, the Authorization Server MUST
    send an HTTP <tt>GET</tt> request to the <tt>request_uri</tt>
    to retrieve the referenced Request Object, unless it is already cached, and parse it
    to recreate the Authorization Request parameters.
</p>

<p>Note that the RP SHOULD use a unique URI for each
    request utilizing distinct parameters, or otherwise
    prevent the Authorization Server from caching the <tt>request_uri</tt>.

</p>

<p>The following is a non-normative example of this fetch
    process:
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /request.jwt HTTP/1.1
  Host: client.example.org
</pre>
</div>
<a name="RequestUriRationale"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.2.4"></a>

<h3>6.2.4.&nbsp;
    "request_uri" Rationale</h3>

<p>
    There are several reasons that one might choose to use the
    <tt>request_uri</tt> parameter:

</p>

<p>
</p>
<ol class="text">
    <li>
        The set of request parameters can become large, and can exceed browser
        URI size limitations. Passing the request parameters by reference
        can solve this problem.

    </li>
    <li>
        Passing a <tt>request_uri</tt> value, rather than
        a complete request by value, can reduce request latency.

    </li>
    <li>
        Most requests for Claims from an RP are constant.
        The <tt>request_uri</tt> is a way of creating
        and sometimes also signing and encrypting a constant set of
        request parameters in advance.
        (The <tt>request_uri</tt> value becomes an "artifact"
        representing a particular fixed set of request parameters.)

    </li>
    <li>
        Pre-registering a fixed set of request parameters at Registration time
        enables OPs to cache and pre-validate the request parameters at
        Registration time, meaning they need not be retrieved at request time.

    </li>
    <li>
        Pre-registering a fixed set of request parameters at
        Registration time enables OPs to vet the contents of
        the request from consumer protection and other points
        of views, either itself or by utilizing a third party.

    </li>
</ol>
<p>

</p>
<a name="JWTRequestValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.3"></a>

<h3>6.3.&nbsp;
    Validating JWT-Based Requests</h3>

<p>
    When the <tt>request</tt> or
    <tt>request_uri</tt> Authorization Request parameters
    are used, additional steps must be performed to validate the
    Authentication Request beyond those specified in
    Sections <a class="info"
                href="#AuthRequestValidation">3.1.2.2<span> (</span><span
        class="info">Authentication Request Validation</span><span>)</span></a>,
    <a class="info"
       href="#ImplicitValidation">3.2.2.2<span> (</span><span
            class="info">Authentication Request Validation</span><span>)</span></a>, or
    <a class="info"
       href="#HybridValidation">3.3.2.2<span> (</span><span
            class="info">Authentication Request Validation</span><span>)</span></a>.
    These steps are to validate the JWT containing the Request Object
    and to validate the Request Object itself.


</p>
<a name="EncryptedRequestObject"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.3.1"></a>

<h3>6.3.1.&nbsp;
    Encrypted Request Object</h3>

<p>
    If the Authorization Server has advertised JWE encryption algorithms
    in the <tt>request_object_encryption_alg_values_supported</tt> and
    <tt>request_object_encryption_enc_values_supported</tt> elements of its
    Discovery document <a class="info" href="#OpenID.Discovery">[OpenID.Discovery]<span> (</span><span
        class="info">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November&nbsp;2014.</span><span>)</span></a>,
    or has supplied encryption algorithms by other means,
    these are used by the Client to encrypt the JWT.

</p>

<p>
    The Authorization Server MUST decrypt the JWT in accordance with
    the <a class="info" href="#JWE">JSON Web
    Encryption<span> (</span><span class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July&nbsp;2014.</span><span>)</span></a>
    [JWE] specification.
    The result MAY be either a signed or unsigned (plaintext) Request Object.
    In the former case, signature validation MUST be performed
    as defined in <a class="info" href="#SignedRequestObject">Section&nbsp;6.3.2<span> (</span><span
        class="info">Signed Request Object</span><span>)</span></a>.

</p>

<p>
    The Authorization Server MUST return an error if decryption fails.

</p>
<a name="SignedRequestObject"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.3.2"></a>

<h3>6.3.2.&nbsp;
    Signed Request Object</h3>

<p>
    To perform Signature Validation,
    the <tt>alg</tt> Header Parameter in the JOSE Header MUST match the value
    of the <tt>request_object_signing_alg</tt> set during
    Client Registration <a class="info" href="#OpenID.Registration">[OpenID.Registration]<span> (</span><span
        class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November&nbsp;2014.</span><span>)</span></a>
    or a value that was
    pre-registered by other means.
    The signature MUST be validated against the appropriate key
    for that <tt>client_id</tt>
    and algorithm.

</p>

<p>
    The Authorization Server MUST return an error if signature validation fails.

</p>
<a name="RequestParameterValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.6.3.3"></a>

<h3>6.3.3.&nbsp;
    Request Parameter Assembly and Validation</h3>

<p>
    The Authorization Server MUST assemble
    the set of Authorization Request parameters to be used
    from the Request Object value
    and the OAuth 2.0 Authorization Request parameters
    (minus the <tt>request</tt> or
    <tt>request_uri</tt> parameters).
    If the same parameter exists both in
    the Request Object and the OAuth Authorization Request parameters,
    the parameter in the Request Object is used.
    Using the assembled set of Authorization Request parameters,
    the Authorization Server then validates the request
    the normal manner for the flow being used, as specified in
    Sections <a class="info"
                href="#AuthRequestValidation">3.1.2.2<span> (</span><span
        class="info">Authentication Request Validation</span><span>)</span></a>,
    <a class="info"
       href="#ImplicitValidation">3.2.2.2<span> (</span><span
            class="info">Authentication Request Validation</span><span>)</span></a>, or
    <a class="info"
       href="#HybridValidation">3.3.2.2<span> (</span><span
            class="info">Authentication Request Validation</span><span>)</span></a>.

</p>
<a name="SelfIssued"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.7"></a>

<h3>7.&nbsp;
    Self-Issued OpenID Provider</h3>

<p>
    OpenID Connect supports Self-Issued OpenID Providers -
    personal, self-hosted OPs that issue self-signed ID Tokens.
    Self-Issued OPs use the special Issuer Identifier
    <tt>https://self-issued.me</tt>.

</p>

<p>
    The messages used to communicate with Self-Issued OPs are
    mostly the same as those used to communicate with other OPs.
    Specifications for the few additional parameters used and
    for the values of some parameters in the Self-Issued case
    are defined in this section.

</p>
<a name="SelfIssuedDiscovery"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.7.1"></a>

<h3>7.1.&nbsp;
    Self-Issued OpenID Provider Discovery</h3>

<p>
    If the input identifier for the discovery process
    contains the domain self-issued.me, dynamic discovery is not performed.
    Instead, then the following static configuration values are used:

</p>

<p>
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "authorization_endpoint":
     "openid:",
   "issuer":
     "https://self-issued.me",
   "scopes_supported":
     ["openid", "profile", "email", "address", "phone"],
   "response_types_supported":
     ["id_token"],
   "subject_types_supported":
     ["pairwise"],
   "id_token_signing_alg_values_supported":
     ["RS256"],
   "request_object_signing_alg_values_supported":
     ["none", "RS256"]
  }
</pre>
</div>
<p>


</p>

<p>
    NOTE: The OpenID Foundation plans to host the OpenID Provider site
    <tt>https://self-issued.me/</tt>,
    including its WebFinger service, so that performing discovery on it
    returns the above static discovery information, enabling RPs
    to not need any special processing for discovery of the Self-Issued OP.
    This site will be hosted on an experimental basis.
    Production implementations should not take a dependency upon it
    without a subsequent commitment by the OpenID Foundation
    to host the site in a manner intended for production use.

</p>
<a name="SelfIssuedRegistration"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.7.2"></a>

<h3>7.2.&nbsp;
    Self-Issued OpenID Provider Registration</h3>

<p>
    When using a Self-Issued OP, registration is not required.
    The Client can proceed without registration as if it had
    registered with the OP and obtained the following
    Client Registration Response:

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>client_id</dt>
        <dd>

            <tt>redirect_uri</tt> value of the Client.

        </dd>
        <dt>client_secret_expires_at</dt>
        <dd>

            0

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    NOTE: The OpenID Foundation plans to host the (stateless) endpoint
    <tt>https://self-issued.me/registration/1.0/</tt>
    that returns the response above, enabling RPs to not need
    any special processing for registration with the Self-Issued OP.
    This site will be hosted on an experimental basis.
    Production implementations should not take a dependency upon it
    without a subsequent commitment by the OpenID Foundation
    to host the site in a manner intended for production use.

</p>
<a name="RegistrationParameter"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.7.2.1"></a>

<h3>7.2.1.&nbsp;
    Providing Information with the "registration" Request Parameter</h3>

<p>
    OpenID Connect defines the following Authorization Request parameter
    to enable Clients to provide additional registration information to
    Self-Issued OpenID Providers:

</p>
<blockquote class="text">
    <dl>
        <dt>registration</dt>
        <dd>

            OPTIONAL.
            This parameter is used by the Client to provide information about itself
            to a Self-Issued OP that would normally be provided to an OP during
            Dynamic Client Registration.
            The value is a JSON object containing Client metadata values,
            as defined in Section 2.1 of the
            <a class="info" href="#OpenID.Registration">OpenID
                Connect Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November&nbsp;2014.</span><span>)</span></a>
            [OpenID.Registration]
            specification.
            The <tt>registration</tt> parameter SHOULD NOT be used
            when the OP is not a Self-Issued OP.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    None of this information is REQUIRED by Self-Issued OPs,
    so the use of this parameter is OPTIONAL.

</p>

<p>
    The <tt>registration</tt> parameter value is represented
    in an OAuth 2.0 request as a UTF-8 encoded JSON object
    (which ends up being form-urlencoded when passed as an OAuth parameter).
    When used in a Request Object value, per <a class="info"
                                                href="#RequestObject">Section&nbsp;6.1<span> (</span><span
        class="info">Passing a Request Object by Value</span><span>)</span></a>,
    the JSON object is used as the value of the
    <tt>registration</tt> member.

</p>

<p>
    The Registration parameters that would typically be used in requests
    to Self-Issued OPs are
    <tt>policy_uri</tt>,
    <tt>tos_uri</tt>, and
    <tt>logo_uri</tt>.
    If the Client uses more than one Redirection URI, the
    <tt>redirect_uris</tt>
    parameter would be used to register them.
    Finally, if the Client is requesting encrypted responses, it would typically use the
    <tt>jwks_uri</tt>,
    <tt>id_token_encrypted_response_alg</tt> and
    <tt>id_token_encrypted_response_enc</tt> parameters.

</p>
<a name="SelfIssuedRequest"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.7.3"></a>

<h3>7.3.&nbsp;
    Self-Issued OpenID Provider Request</h3>

<p>The Client sends the Authentication Request to the Authorization Endpoint
    with the following parameters:
</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>scope</dt>
        <dd>

            REQUIRED.
            <tt>scope</tt> parameter value,
            as specified in <a class="info"
                               href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
                class="info">Authorization Endpoint</span><span>)</span></a>.

        </dd>
        <dt>response_type</dt>
        <dd>

            REQUIRED. Constant string value <tt>id_token</tt>.

        </dd>
        <dt>client_id</dt>
        <dd>

            REQUIRED.
            Client ID value for the Client, which in this case contains the
            <tt>redirect_uri</tt> value of the Client.
            Since the Client's
            <tt>redirect_uri</tt> URI value is communicated
            as the Client ID,
            a <tt>redirect_uri</tt> parameter
            is NOT REQUIRED to also be included in the request.

        </dd>
        <dt>id_token_hint</dt>
        <dd>

            OPTIONAL.
            <tt>id_token_hint</tt> parameter value,
            as specified in <a class="info"
                               href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
                class="info">Authorization Endpoint</span><span>)</span></a>.
            If the ID Token is encrypted to the Self-Issued OP,
            the <tt>sub</tt> (subject)
            of the signed ID Token MUST be sent as the
            <tt>kid</tt> (Key ID) of the JWE.
            Encrypting content to Self-Issued OPs is currently only supported when
            the OP's JWK key type is <tt>RSA</tt> and the encryption
            algorithm used is <tt>RSA1_5</tt>.

        </dd>
        <dt>claims</dt>
        <dd>

            OPTIONAL.
            <tt>claims</tt> parameter value,
            as specified in <a class="info" href="#ClaimsParameter">Section&nbsp;5.5<span> (</span><span
                class="info">Requesting Claims using the "claims" Request Parameter</span><span>)</span></a>.

        </dd>
        <dt>registration</dt>
        <dd>

            OPTIONAL.
            This parameter is used by the Client to provide information about itself
            to a Self-Issued OP that would normally be provided to an OP during
            Dynamic Client Registration,
            as specified in <a class="info"
                               href="#RegistrationParameter">Section&nbsp;7.2.1<span> (</span><span
                class="info">Providing Information with the "registration" Request Parameter</span><span>)</span></a>.

        </dd>
        <dt>request</dt>
        <dd>

            OPTIONAL.
            Request Object value, as specified in <a class="info"
                                                     href="#RequestObject">Section&nbsp;6.1<span> (</span><span
                class="info">Passing a Request Object by Value</span><span>)</span></a>.
            The Request Object MAY be encrypted to the Self-Issued OP by the Client.
            In this case, the <tt>sub</tt> (subject) of
            a previously issued ID Token for this Client
            MUST be sent as the <tt>kid</tt> (Key ID) of the JWE.
            Encrypting content to Self-Issued OPs is currently only supported when
            the OP's JWK key type is <tt>RSA</tt> and the encryption
            algorithm used is <tt>RSA1_5</tt>.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    Other parameters MAY be sent.
    Note that all Claims are returned in the ID Token.

</p>

<p>The entire URL MUST NOT exceed 2048 ASCII characters.
</p>

<p>
    The following is a non-normative example
    HTTP 302 redirect response by the Client, which triggers
    the User Agent to make an Authentication Request
    to the Self-Issued OpenID Provider
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 302 Found
  Location: openid://?
    response_type=id_token
    &amp;client_id=https%3A%2F%2Fclient.example.org%2Fcb
    &amp;scope=openid%20profile
    &amp;state=af0ifjsldkj
    &amp;nonce=n-0S6_WzA2Mj
    &amp;registration=%7B%22logo_uri%22%3A%22https%3A%2F%2F
      client.example.org%2Flogo.png%22%7D
</pre>
</div>
<a name="SelfIssuedResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.7.4"></a>

<h3>7.4.&nbsp;
    Self-Issued OpenID Provider Response</h3>

<p>
    OpenID Connect defines the following Claim
    for use in Self-Issued OpenID Provider Responses:

</p>
<blockquote class="text">
    <dl>
        <dt>sub_jwk</dt>
        <dd>

            REQUIRED.
            Public key used to check the signature of an ID Token
            issued by a Self-Issued OpenID Provider,
            as specified in <a class="info" href="#SelfIssued">Section&nbsp;7<span> (</span><span
                class="info">Self-Issued OpenID Provider</span><span>)</span></a>.
            The key is a bare key in JWK <a class="info"
                                            href="#JWK">[JWK]<span> (</span><span
                class="info">Jones, M., “JSON Web Key (JWK),” July&nbsp;2014.</span><span>)</span></a> format
            (not an X.509 certificate value).
            The <tt>sub_jwk</tt> value is a JSON object.
            Use of the <tt>sub_jwk</tt> Claim
            is NOT RECOMMENDED when the OP is not Self-Issued.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    The Self-Issued OpenID Provider response is the same as the normal Implicit Flow
    response with the following refinements. Since it is an Implicit Flow
    response, the response parameters will be returned in the URL fragment component,
    unless a different Response Mode was specified.

</p>

<p>
</p>
<ol class="text">
    <li>
        The <tt>iss</tt> (issuer) Claim Value is
        <tt>https://self-issued.me</tt>.

    </li>
    <li>
        A <tt>sub_jwk</tt> Claim is present, with its value being
        the public key used to check the signature of the ID Token.

    </li>
    <li>
        The <tt>sub</tt> (subject) Claim
        value is the base64url encoded representation of
        the thumbprint of
        the key in the <tt>sub_jwk</tt> Claim.
        This thumbprint value is computed as
        the SHA-256 hash of
        the octets of the UTF-8 representation of
        a JWK constructed containing only the REQUIRED members to represent the key,
        with the member names sorted into lexicographic order,
        and with no white space or line breaks.
        For instance,
        when the <tt>kty</tt> value is
        <tt>RSA</tt>, the member names
        <tt>e</tt>,
        <tt>kty</tt>, and
        <tt>n</tt>
        are the ones present in the constructed JWK used
        in the thumbprint computation and appear in that order;
        when the <tt>kty</tt> value is
        <tt>EC</tt>, the member names
        <tt>crv</tt>,
        <tt>kty</tt>,
        <tt>x</tt>, and
        <tt>y</tt>
        are present in that order.
        Note that this thumbprint calculation is the same as that defined in
        the JWK Thumbprint <a class="info" href="#JWK.Thumbprint">[JWK.Thumbprint]<span> (</span><span
            class="info">Jones, M., “JSON Web Key (JWK) Thumbprint,” July&nbsp;2014.</span><span>)</span></a>
        specification.

    </li>
    <li>
        No Access Token is returned for accessing a UserInfo Endpoint,
        so all Claims returned MUST be in the ID Token.

    </li>
</ol>
<p>

</p>
<a name="SelfIssuedValidation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.7.5"></a>

<h3>7.5.&nbsp;
    Self-Issued ID Token Validation</h3>

<p>
    To validate the ID Token received, the Client MUST do the following:

</p>

<p>
</p>
<ol class="text">
    <li>
        The Client MUST validate that the value of the <tt>iss</tt> (issuer) Claim is <tt>https://self-isued.me</tt>.
        If <tt>iss</tt> contains a different value,
        the ID Token is not Self-Issued, and instead
        it MUST be validated according to
        <a class="info" href="#IDTokenValidation">Section&nbsp;3.1.3.7<span> (</span><span
                class="info">ID Token Validation</span><span>)</span></a>.

    </li>
    <li>
        The Client MUST validate that the
        <tt>aud</tt> (audience) Claim
        contains the value of the <tt>redirect_uri</tt>
        that the Client sent in the Authentication Request as an audience.

    </li>
    <li>
        The Client MUST validate the signature of the ID Token according to
        <a class="info" href="#JWS">JWS<span> (</span><span
                class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>
        [JWS] using the algorithm specified in the
        <tt>alg</tt> Header Parameter of the JOSE Header,
        using the key in the <tt>sub_jwk</tt> Claim;
        the key is a bare key in JWK format
        (not an X.509 certificate value).

    </li>
    <li>
        The <tt>alg</tt> value SHOULD be the default of
        <tt>RS256</tt>.
        It MAY also be <tt>ES256</tt>.

    </li>
    <li>
        The Client MUST validate that the <tt>sub</tt> Claim
        value is the base64url encoded representation of
        the thumbprint of
        the key in the <tt>sub_jwk</tt> Claim,
        as specified in <a class="info" href="#SelfIssuedResponse">Section&nbsp;7.4<span> (</span><span
            class="info">Self-Issued OpenID Provider Response</span><span>)</span></a>.

    </li>
    <li>
        The current time MUST be before the time represented by the
        <tt>exp</tt> Claim
        (possibly allowing for some small leeway to account for clock skew).

    </li>
    <li>
        The <tt>iat</tt> Claim can be used to reject tokens that
        were issued too far away from the current time, limiting the amount of
        time that nonces need to be stored to prevent attacks.
        The acceptable range is Client specific.

    </li>
    <li>
        If a nonce value was sent in the Authentication Request,
        a <tt>nonce</tt> Claim MUST be present
        and its value checked to verify that
        it is the same value as the one that was sent in the Authentication Request.
        The Client SHOULD check the <tt>nonce</tt> value
        for replay attacks.
        The precise method for detecting replay attacks is Client specific.

    </li>
</ol>
<p>

</p>

<p>The following is a non-normative example of a base64url decoded
    Self-Issued ID Token
    (with line wraps within values for display purposes only):
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "iss": "https://self-issued.me",
   "sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
   "aud": "https://client.example.org/cb",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "sub_jwk": {
     "kty":"RSA",
     "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
     4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
     tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
     QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
     SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
     w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "e":"AQAB"
    }
  }
</pre>
</div>
<a name="SubjectIDTypes"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.8"></a>

<h3>8.&nbsp;
    Subject Identifier Types</h3>

<p>
    A Subject Identifier is a locally unique and never
    reassigned identifier within the Issuer for the End-User,
    which is intended to be consumed by the Client.
    Two Subject Identifier types are defined by this specification:

</p>
<blockquote class="text">
    <dl>
        <dt>public</dt>
        <dd>

            This provides the same <tt>sub</tt> (subject) value to all Clients.
            It is the default if the provider has no <tt>subject_types_supported</tt>
            element in its discovery document.

        </dd>
        <dt>pairwise</dt>
        <dd>

            This provides a different <tt>sub</tt>
            value to each Client, so as not to enable Clients to correlate
            the End-User's activities without permission.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    The OpenID Provider's Discovery document SHOULD list
    its supported Subject Identifier types in the
    <tt>subject_types_supported</tt> element.
    If there is more than one type listed in the array, the Client MAY elect to
    provide its preferred identifier type using the
    <tt>subject_type</tt> parameter during Registration.

</p>
<a name="PairwiseAlg"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.8.1"></a>

<h3>8.1.&nbsp;
    Pairwise Identifier Algorithm</h3>

<p>
    When pairwise Subject Identifiers are used,
    the OpenID Provider MUST calculate a unique
    <tt>sub</tt> (subject) value for each
    Sector Identifier. The Subject Identifier value MUST NOT be reversible
    by any party other than the OpenID Provider.

</p>

<p>
    Providers that use pairwise <tt>sub</tt> values
    and support
    <a class="info" href="#OpenID.Registration">Dynamic Client
        Registration<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November&nbsp;2014.</span><span>)</span></a>
    [OpenID.Registration]
    SHOULD use the <tt>sector_identifier_uri</tt> parameter.
    It provides a way for a group of websites under common administrative
    control to have consistent pairwise <tt>sub</tt>
    values independent of the individual domain names.
    It also provides a way for Clients to change
    <tt>redirect_uri</tt> domains without having to
    reregister all of their users.

</p>

<p>If the Client has not provided a value for
    <tt>sector_identifier_uri</tt> in
    <a class="info" href="#OpenID.Registration">Dynamic Client
        Registration<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November&nbsp;2014.</span><span>)</span></a>
    [OpenID.Registration],
    the Sector Identifier
    used for pairwise identifier calculation is the host component
    of the registered <tt>redirect_uri</tt>.
    If there are multiple hostnames in the registered
    <tt>redirect_uris</tt>, the Client MUST register a
    <tt>sector_identifier_uri</tt>.
</p>

<p>When a <tt>sector_identifier_uri</tt>
    is provided, the host component of that URL is used as
    the Sector Identifier for the pairwise identifier calculation.
    The value of the <tt>sector_identifier_uri</tt>
    MUST be a URL using the <tt>https</tt> scheme that points to
    a JSON file containing an array of
    <tt>redirect_uri</tt> values.
    The values of the registered <tt>redirect_uris</tt>
    MUST be included in the elements of the array.

</p>

<p>
    Any algorithm with the following properties
    can be used by OpenID Providers to
    calculate pairwise Subject Identifiers:

</p>
<ul class="text">
    <li>
        The Subject Identifier value MUST NOT be reversible
        by any party other than the OpenID Provider.

    </li>
    <li>
        Distinct Sector Identifier values MUST result in
        distinct Subject Identifier values.

    </li>
    <li>
        The algorithm MUST be deterministic.

    </li>
</ul>
<p>

</p>

<p>
    Three example methods are:

</p>
<ol class="text">
    <li>
        The Sector Identifier can be concatenated with a local account ID and a salt
        value that is kept secret by the Provider. The concatenated string is then
        hashed using an appropriate algorithm.
        <br>
        <br>

        Calculate <tt>sub</tt> = SHA-256 ( sector_identifier || local_account_id || salt ).
        <br>
        <br>


    </li>
    <li>
        The Sector Identifier can be concatenated with a local account ID and a salt
        value that is kept secret by the Provider. The concatenated string is then
        encrypted using an appropriate algorithm.
        <br>
        <br>

        Calculate <tt>sub</tt> = AES-128 ( sector_identifier || local_account_id || salt ).
        <br>
        <br>


    </li>
    <li>
        The Issuer creates a Globally Unique Identifier (GUID) for the pair of
        Sector Identifier and local account ID and stores this value.

    </li>
</ol>
<p>

</p>
<a name="ClientAuthentication"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.9"></a>

<h3>9.&nbsp;
    Client Authentication</h3>

<p>
    This section defines a set of Client Authentication methods
    that are used by Clients to authenticate to the Authorization Server
    when using the Token Endpoint.
    During Client Registration, the RP (Client) MAY register a Client Authentication method.
    If no method is registered, the default method is <tt>client_secret_basic</tt>.

</p>

<p>These Client Authentication methods are:
</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>client_secret_basic</dt>
        <dd>

            Clients that have received a <tt>client_secret</tt> value
            from the Authorization Server authenticate with the Authorization Server
            in accordance with Section 2.3.1 of <a class="info"
                                                   href="#RFC6749">OAuth
            2.0<span> (</span><span
                    class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
            [RFC6749] using the HTTP Basic authentication scheme.

        </dd>
        <dt>client_secret_post</dt>
        <dd>

            Clients that have received a <tt>client_secret</tt> value
            from the Authorization Server, authenticate with the Authorization Server
            in accordance with Section 2.3.1 of <a class="info"
                                                   href="#RFC6749">OAuth
            2.0<span> (</span><span
                    class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
            [RFC6749] by including the Client Credentials in the request body.

        </dd>
        <dt>client_secret_jwt</dt>
        <dd>

            Clients that have received a <tt>client_secret</tt> value
            from the Authorization Server create a JWT using an
            HMAC SHA algorithm, such as HMAC SHA-256.
            The HMAC (Hash-based Message Authentication Code) is calculated using
            the octets of the UTF-8 representation of
            the <tt>client_secret</tt> as the shared key.

        </dd>
        <dt></dt>
        <dd>
            The Client authenticates in accordance with <a class="info"
                                                           href="#OAuth.JWT">JSON
            Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants<span> (</span><span
                    class="info">Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>
            [OAuth.JWT] and
            <a class="info" href="#OAuth.Assertions">Assertion
                Framework for OAuth 2.0 Client Authentication and Authorization Grants<span> (</span><span class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>
            [OAuth.Assertions].
            The JWT MUST contain the following REQUIRED Claim Values and
            MAY contain the following OPTIONAL Claim Values:

        </dd>
        <dt></dt>
        <dd>

            <blockquote class="text">
                <dl>
                    <dt>iss</dt>
                    <dd>

                        REQUIRED.
                        Issuer.
                        This MUST contain the <tt>client_id</tt> of the OAuth Client.

                    </dd>
                    <dt>sub</dt>
                    <dd>

                        REQUIRED.
                        Subject.
                        This MUST contain the <tt>client_id</tt> of the OAuth Client.

                    </dd>
                    <dt>aud</dt>
                    <dd>

                        REQUIRED.
                        Audience.
                        The <tt>aud</tt> (audience) Claim.
                        Value that identifies the Authorization Server as an intended audience.
                        The Authorization Server MUST verify that it is an intended audience
                        for the token.
                        The Audience SHOULD be the URL of the
                        Authorization Server's Token Endpoint.

                    </dd>
                    <dt>jti</dt>
                    <dd>

                        REQUIRED.
                        JWT ID.
                        A unique identifier for the token,
                        which can be used to prevent reuse of the token.
                        These tokens MUST only be used once,
                        unless conditions for reuse were negotiated between the parties;
                        any such negotiation is beyond the scope of this specification.

                    </dd>
                    <dt>exp</dt>
                    <dd>

                        REQUIRED.
                        Expiration time on or after which the ID Token MUST NOT be
                        accepted for processing.

                    </dd>
                    <dt>iat</dt>
                    <dd>

                        OPTIONAL.
                        Time at which the JWT was issued.

                    </dd>
                </dl>
            </blockquote>

        </dd>
        <dt></dt>
        <dd>
            The JWT MAY contain other Claims.
            Any Claims used that are not understood MUST be ignored.

        </dd>
        <dt></dt>
        <dd>The authentication token MUST be sent as the value of the
            <a class="info" href="#OAuth.Assertions">[OAuth.Assertions]<span> (</span><span
                    class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>
            <tt>client_assertion</tt> parameter.
        </dd>
        <dt></dt>
        <dd>The value of the
            <a class="info" href="#OAuth.Assertions">[OAuth.Assertions]<span> (</span><span
                    class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>
            <tt>client_assertion_type</tt> parameter
            MUST be "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
            per <a class="info" href="#OAuth.JWT">[OAuth.JWT]<span> (</span><span
                    class="info">Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>.
        </dd>
        <dt>private_key_jwt</dt>
        <dd>

            Clients that have registered a public key sign a JWT using
            that key.
            The Client authenticates in accordance with <a class="info"
                                                           href="#OAuth.JWT">JSON
            Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants<span> (</span><span
                    class="info">Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>
            [OAuth.JWT] and
            <a class="info" href="#OAuth.Assertions">Assertion
                Framework for OAuth 2.0 Client Authentication and Authorization Grants<span> (</span><span class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>
            [OAuth.Assertions].
            The JWT MUST contain the following REQUIRED Claim Values and
            MAY contain the following OPTIONAL Claim Values:
        </dd>
        <dt></dt>
        <dd>

            <blockquote class="text">
                <dl>
                    <dt>iss</dt>
                    <dd>

                        REQUIRED.
                        Issuer.
                        This MUST contain the <tt>client_id</tt> of the OAuth Client.

                    </dd>
                    <dt>sub</dt>
                    <dd>

                        REQUIRED.
                        Subject.
                        This MUST contain the <tt>client_id</tt> of the OAuth Client.

                    </dd>
                    <dt>aud</dt>
                    <dd>

                        REQUIRED.
                        Audience.
                        The <tt>aud</tt> (audience) Claim.
                        Value that identifies the Authorization Server as an intended audience.
                        The Authorization Server MUST verify that it is an intended audience
                        for the token.
                        The Audience SHOULD be the URL of the
                        Authorization Server's Token Endpoint.

                    </dd>
                    <dt>jti</dt>
                    <dd>

                        REQUIRED.
                        JWT ID.
                        A unique identifier for the token,
                        which can be used to prevent reuse of the token.
                        These tokens MUST only be used once,
                        unless conditions for reuse were negotiated between the parties;
                        any such negotiation is beyond the scope of this specification.

                    </dd>
                    <dt>exp</dt>
                    <dd>

                        REQUIRED.
                        Expiration time on or after which the ID Token MUST NOT be
                        accepted for processing.

                    </dd>
                    <dt>iat</dt>
                    <dd>

                        OPTIONAL.
                        Time at which the JWT was issued.

                    </dd>
                </dl>
            </blockquote>

        </dd>
        <dt></dt>
        <dd>
            The JWT MAY contain other Claims.
            Any Claims used that are not understood MUST be ignored.

        </dd>
        <dt></dt>
        <dd>The authentication token MUST be sent as the value of the
            <a class="info" href="#OAuth.Assertions">[OAuth.Assertions]<span> (</span><span
                    class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>
            <tt>client_assertion</tt> parameter.
        </dd>
        <dt></dt>
        <dd>The value of the
            <a class="info" href="#OAuth.Assertions">[OAuth.Assertions]<span> (</span><span
                    class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>
            <tt>client_assertion_type</tt> parameter
            MUST be "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
            per <a class="info" href="#OAuth.JWT">[OAuth.JWT]<span> (</span><span
                    class="info">Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>.
        </dd>
        <dt></dt>
        <dd>

            <p>
                For example
                (with line wraps within values for display purposes only):

            </p>

            <div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  grant_type=authorization_code&amp;
    code=i1WsRn1uB1&amp;
    client_id=s6BhdRkqt3&amp;
    client_assertion_type=
    urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&amp;
    client_assertion=PHNhbWxwOl ... ZT
</pre>
            </div>

        </dd>
        <dt>none</dt>
        <dd>

            The Client does not authenticate itself at the Token Endpoint,
            either because it uses only the Implicit Flow (and so does not use the Token Endpoint)
            or because it is a Public Client with no Client Secret or other authentication mechanism.

        </dd>
    </dl>
</blockquote>
<p>

</p>
<a name="SigEnc"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.10"></a>

<h3>10.&nbsp;
    Signatures and Encryption</h3>

<p>
    Depending on the transport through which the messages are sent, the
    integrity of the message might not be guaranteed and the originator of the
    message might not be authenticated. To mitigate these risks,
    ID Token, UserInfo Response, Request Object,
    and Client Authentication JWT values can utilize
    <a class="info" href="#JWS">JSON Web Signature
        (JWS)<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>
    [JWS] to sign their contents.
    To achieve message confidentiality, these values can also use
    <a class="info" href="#JWE">JSON Web Encryption
        (JWE)<span> (</span><span class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July&nbsp;2014.</span><span>)</span></a>
    [JWE] to encrypt their contents.

</p>

<p>
    When the message is both signed and encrypted, it MUST be
    signed first and then encrypted, per <a class="info"
                                            href="#SigningOrder">Section&nbsp;16.14<span> (</span><span
        class="info">Signing and Encryption Order</span><span>)</span></a>,
    with the result being a Nested JWT, as specified in <a class="info"
                                                           href="#JWT">[JWT]<span> (</span><span
        class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>.
    Note that all JWE encryption methods perform integrity checking.

</p>

<p>
    The OP advertises its supported signing and encryption algorithms
    in its Discovery document,
    or may supply this information by other means.
    The RP declares its required signing and encryption algorithms
    in its Dynamic Registration request,
    or may communicate this information by other means.

</p>

<p>
    The OP advertises its public keys
    via its Discovery document,
    or may supply this information by other means.
    The RP declares its public keys
    via its Dynamic Registration request,
    or may communicate this information by other means.

</p>
<a name="Signing"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.10.1"></a>

<h3>10.1.&nbsp;
    Signing</h3>

<p>
    The signing party MUST select a signature algorithm
    based on the algorithms supported by the recipient.

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>Asymmetric Signatures</dt>
        <dd>

            When using RSA or ECDSA Signatures,
            the <tt>alg</tt> Header Parameter value
            of the JOSE Header MUST be set to an appropriate algorithm
            as defined in <a class="info" href="#JWA">JSON Web
            Algorithms<span> (</span><span
                    class="info">Jones, M., “JSON Web Algorithms (JWA),” July&nbsp;2014.</span><span>)</span></a> [JWA].
            The private key used to sign the content MUST be associated with
            a public key used for signature verification published by the sender
            in its JWK Set document.
            If there are multiple keys in the referenced JWK Set document, a
            <tt>kid</tt> value MUST be provided in the JOSE Header.
            The key usage of the respective keys MUST support signing.

        </dd>
        <dt>Symmetric Signatures</dt>
        <dd>

            When using MAC-based signatures,
            the <tt>alg</tt> Header Parameter value
            of the JOSE Header MUST be set to a MAC algorithm,
            as defined in <a class="info" href="#JWA">JSON Web
            Algorithms<span> (</span><span
                    class="info">Jones, M., “JSON Web Algorithms (JWA),” July&nbsp;2014.</span><span>)</span></a> [JWA].
            The MAC key used is
            the octets of the UTF-8 representation of
            the <tt>client_secret</tt> value.
            See <a class="info" href="#SymmetricKeyEntropy">Section&nbsp;16.19<span> (</span><span
                class="info">Symmetric Key Entropy</span><span>)</span></a> for a discussion of
            entropy requirements for <tt>client_secret</tt> values.
            Symmetric signatures MUST NOT be used by public (non-confidential) Clients
            because of their inability to keep secrets.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    See <a class="info" href="#NeedForSignedRequests">Section&nbsp;16.20<span> (</span><span
        class="info">Need for Signed Requests</span><span>)</span></a> for Security Considerations
    about the need for signed requests.

</p>
<a name="RotateSigKeys"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.10.1.1"></a>

<h3>10.1.1.&nbsp;
    Rotation of Asymmetric Signing Keys</h3>

<p>Rotation of signing keys can be accomplished with the following approach. The signer publishes
    its keys in a JWK Set at its <tt>jwks_uri</tt> location
    and includes the <tt>kid</tt> of the
    signing key in the JOSE Header of each message
    to indicate to the verifier which key is to be used to validate the signature. Keys can be rolled over
    by periodically adding new keys to the JWK Set at the <tt>jwks_uri</tt> location.
    The signer can begin using a new key at its
    discretion and signals the change to the verifier using the <tt>kid</tt> value.
    The verifier knows to go back to the <tt>jwks_uri</tt> location
    to re-retrieve the keys when it sees an unfamiliar
    <tt>kid</tt> value. The JWK Set document at the <tt>jwks_uri</tt>
    SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a
    smooth transition.

</p>
<a name="Encryption"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.10.2"></a>

<h3>10.2.&nbsp;
    Encryption</h3>

<p>
    The encrypting party MUST select an encryption algorithm
    based on the algorithms supported by the recipient.

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>Asymmetric Encryption: RSA</dt>
        <dd>

            The public key to which the content was encrypted MUST be
            a public key used for encryption published by the recipient
            in its JWK Set document.
            If there are multiple keys in the referenced JWK Set document, a
            <tt>kid</tt> value MUST be provided in the JOSE Header.
            Use the supported RSA encryption algorithm to encrypt a random
            Content Encryption Key to be used for encrypting
            the signed JWT.
            The key usage of the respective keys MUST include encryption.

        </dd>
        <dt>Asymmetric Encryption: Elliptic Curve</dt>
        <dd>

            Create an ephemeral Elliptic Curve public key for the <tt>epk</tt>
            element of the JOSE Header.
            The other public key used for the key agreement computation MUST be
            a public key published by the recipient
            in its JWK Set document.
            If there are multiple keys in the referenced JWK Set document, a
            <tt>kid</tt> value MUST be provided in the JOSE Header.
            Use the ECDH-ES algorithm to agree upon a
            Content Encryption Key to be used for encrypting
            the signed JWT.
            The key usage of the respective keys MUST support encryption.

        </dd>
        <dt>Symmetric Encryption</dt>
        <dd>

            The symmetric encryption key is derived from the
            <tt>client_secret</tt> value by
            using a left truncated SHA-2 hash of
            the octets of the UTF-8 representation of
            the <tt>client_secret</tt>.
            For keys of 256 or fewer bits, SHA-256 is used;
            for keys of 257-384 bits, SHA-384 is used;
            for keys of 385-512 bits, SHA-512 is used.
            The hash value MUST be left truncated to the appropriate bit length
            for the AES key wrapping or direct encryption algorithm used,
            for instance, truncating the SHA-256 hash
            to 128 bits for <tt>A128KW</tt>.
            If a symmetric key with greater than 512 bits is needed, a different method
            of deriving the key from the <tt>client_secret</tt>
            would have to be defined by an extension.
            Symmetric encryption MUST NOT be used by public (non-confidential) Clients
            because of their inability to keep secrets.

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    See <a class="info" href="#NeedForEncryptedRequests">Section&nbsp;16.21<span> (</span><span
        class="info">Need for Encrypted Requests</span><span>)</span></a> for Security Considerations
    about the need for encrypted requests.

</p>
<a name="RotateEncKeys"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.10.2.1"></a>

<h3>10.2.1.&nbsp;
    Rotation of Asymmetric Encryption Keys</h3>

<p>
    Rotating encryption keys necessarily uses a different process than the one for signing keys because
    the encrypting party starts the process and thus cannot rely on
    a change in <tt>kid</tt> as a signal
    that keys need to change. The encrypting party
    still uses the <tt>kid</tt> Header Parameter in the JWE
    to tell the decrypting party which private key to use to decrypt, however, the encrypting party
    needs to first select the most appropriate key from those provided in the JWK Set at
    the recipient's <tt>jwks_uri</tt> location.

</p>

<p>
    To rotate keys, the decrypting party can publish new keys
    at its <tt>jwks_uri</tt> location
    and remove from the JWK Set those that are being decommissioned.
    The <tt>jwks_uri</tt> SHOULD include a <tt>Cache-Control</tt>
    header in the response that contains a <tt>max-age</tt> directive,
    as defined in <a class="info" href="#RFC2616">RFC
    2616<span> (</span><span class="info">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June&nbsp;1999.</span><span>)</span></a>
    [RFC2616],
    which enables the encrypting party to safely cache the JWK Set and not have to re-retrieve
    the document for every encryption event. The decrypting party SHOULD remove decommissioned keys
    from the JWK Set referenced by <tt>jwks_uri</tt>
    but retain them internally for some reasonable
    period of time, coordinated with the cache duration, to facilitate a smooth transition between keys
    by allowing the encrypting party some time to obtain the new keys. The cache duration SHOULD also
    be coordinated with the issuance of new signing keys, as described in <a class="info"
                                                                             href="#RotateSigKeys">Section&nbsp;10.1.1<span> (</span><span
        class="info">Rotation of Asymmetric Signing Keys</span><span>)</span></a>.

</p>
<a name="OfflineAccess"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.11"></a>

<h3>11.&nbsp;
    Offline Access</h3>

<p>
    OpenID Connect defines the following <tt>scope</tt> value
    to request offline access:

</p>
<blockquote class="text">
    <dl>
        <dt>offline_access</dt>
        <dd>

            OPTIONAL. This scope value requests
            that an OAuth 2.0 Refresh Token be issued that can be used to
            obtain an Access Token that grants access to the End-User's
            UserInfo Endpoint even when the End-User is not present (not logged in).

        </dd>
    </dl>
</blockquote>
<p>

</p>

<p>
    When offline access is requested, a <tt>prompt</tt>
    parameter value of <tt>consent</tt> MUST be used
    unless other conditions for processing the request permitting offline access
    to the requested resources are in place.
    The OP MUST always obtain consent to returning a Refresh Token
    that enables offline access to the requested resources.
    A previously saved user consent is not always sufficient to grant offline access.

</p>

<p>
    Upon receipt of a scope parameter containing the
    <tt>offline_access</tt> value, the Authorization Server:

</p>
<ul class="text">
    <li>
        MUST ensure that the prompt parameter contains
        <tt>consent</tt>
        unless other conditions for processing the request permitting offline access
        to the requested resources are in place;
        unless one or both of these conditions are fulfilled, then
        it MUST ignore the <tt>offline_access</tt> request,

    </li>
    <li>
        MUST ignore the <tt>offline_access</tt> request
        unless the Client is using a <tt>response_type</tt>
        value that would result in an Authorization Code being returned,

    </li>
    <li>
        MUST explicitly receive or have consent for all Clients when
        the registered <tt>application_type</tt>
        is <tt>web</tt>,

    </li>
    <li>
        SHOULD explicitly receive or have consent for all Clients when
        the registered <tt>application_type</tt>
        is <tt>native</tt>.

    </li>
</ul>
<p>

    The use of Refresh Tokens is not exclusive to the
    <tt>offline_access</tt> use case.
    The Authorization Server MAY grant Refresh Tokens
    in other contexts that are beyond the scope of this specification.

</p>
<a name="RefreshTokens"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.12"></a>

<h3>12.&nbsp;
    Using Refresh Tokens</h3>

<p>
    A request to the Token Endpoint can also use a Refresh Token
    by using the <tt>grant_type</tt> value
    <tt>refresh_token</tt>,
    as described in Section 6 of
    <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749].
    This section defines the behaviors for OpenID Connect
    Authorization Servers when Refresh Tokens are used.

</p>
<a name="RefreshingAccessToken"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.12.1"></a>

<h3>12.1.&nbsp;
    Refresh Request</h3>

<p>
    To refresh an Access Token, the Client MUST
    authenticate to the Token Endpoint using the authentication method registered
    for its <tt>client_id</tt>, as documented in
    <a class="info"
       href="#ClientAuthentication">Section&nbsp;9<span> (</span><span
            class="info">Client Authentication</span><span>)</span></a>.
    The Client sends the parameters via HTTP <tt>POST</tt>
    to the Token Endpoint using
    Form Serialization, per <a class="info"
                               href="#FormSerialization">Section&nbsp;13.2<span> (</span><span
        class="info">Form Serialization</span><span>)</span></a>.

</p>

<p>
    The following is a non-normative example of a
    Refresh Request
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  client_id=s6BhdRkqt3
    &amp;client_secret=some_secret12345
    &amp;grant_type=refresh_token
    &amp;refresh_token=8xLOxBtZp8
    &amp;scope=openid%20profile
</pre>
</div>
<p>
    The Authorization Server MUST validate the Refresh Token,
    MUST verify that it was issued to the Client,
    and must verify that the Client successfully authenticated
    it has a Client Authentication method.

</p>
<a name="RefreshTokenResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.12.2"></a>

<h3>12.2.&nbsp;
    Successful Refresh Response</h3>

<p>
    Upon successful validation of the Refresh Token,
    the response body is the Token Response of <a class="info"
                                                  href="#TokenResponse">Section&nbsp;3.1.3.3<span> (</span><span
        class="info">Successful Token Response</span><span>)</span></a>
    except that it might not contain an <tt>id_token</tt>.

</p>

<p>
    If an ID Token is returned as a result of a token refresh request,
    the following requirements apply:
</p>
<ul class="text">
    <li>
        its <tt>iss</tt> Claim Value MUST be the same as
        in the ID Token issued when the original authentication occurred,

    </li>
    <li>
        its <tt>sub</tt> Claim Value MUST be the same as
        in the ID Token issued when the original authentication occurred,

    </li>
    <li>
        its <tt>iat</tt> Claim MUST represent
        the time that the new ID Token is issued,

    </li>
    <li>
        its <tt>aud</tt> Claim Value MUST be the same as
        in the ID Token issued when the original authentication occurred,

    </li>
    <li>
        if the ID Token contains an <tt>auth_time</tt> Claim,
        its value MUST represent the time of the original authentication - not
        the time that the new ID token is issued,

    </li>
    <li>
        its <tt>azp</tt> Claim Value MUST be the same as
        in the ID Token issued when the original authentication occurred;
        if no <tt>azp</tt> Claim was present in the original
        ID Token, one MUST NOT be present in the new ID Token, and

    </li>
    <li>
        otherwise, the same rules apply as apply when issuing an ID Token
        at the time of the original authentication.

    </li>
</ul>
<p>

</p>

<p>
    The following is a non-normative example of a
    Refresh Response:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache

  {
   "access_token": "TlBN45jURg",
   "token_type": "Bearer",
   "refresh_token": "9yNOxJtZa5",
   "expires_in": 3600
  }
</pre>
</div>
<a name="RefreshErrorResponse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.12.3"></a>

<h3>12.3.&nbsp;
    Refresh Error Response</h3>

<p>If the Refresh Request is invalid or unauthorized, the
    Authorization Server returns the
    Token Error Response as defined in Section 5.2 of <a class="info"
                                                         href="#RFC6749">OAuth
        2.0<span> (</span><span
                class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749].
</p>
<a name="Serializations"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.13"></a>

<h3>13.&nbsp;
    Serializations</h3>

<p>
    Messages are serialized using one of the following methods:
</p>
<ol class="text">
    <li>Query String Serialization
    </li>
    <li>Form Serialization
    </li>
    <li>JSON Serialization
    </li>
</ol>
<p>

    This section describes the syntax of these serialization methods;
    other sections describe when they can and must be used.
    Note that not all methods can be used for all messages.

</p>
<a name="QuerySerialization"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.13.1"></a>

<h3>13.1.&nbsp;
    Query String Serialization</h3>

<p>In order to serialize the parameters using the Query String
    Serialization, the Client constructs the string by adding the
    parameters and values to the query component of a URL using the <tt>application/x-www-form-urlencoded</tt> format as
    defined by <a class="info" href="#W3C.REC-html401-19991224">[W3C.REC‑html401‑19991224]<span> (</span><span
            class="info">Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December&nbsp;1999.</span><span>)</span></a>.
    Query String Serialization is typically used in
    HTTP <tt>GET</tt> requests.
    The same serialization method is also used when adding
    parameters to the fragment component of a URL.

</p>

<p>
    The following is a non-normative example of this serialization
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /authorize?
    response_type=code
    &amp;scope=openid
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
  Host: server.example.com
</pre>
</div>
<a name="FormSerialization"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.13.2"></a>

<h3>13.2.&nbsp;
    Form Serialization</h3>

<p>Parameters and their values are Form Serialized by adding the
    parameter names and values to the entity body of the HTTP request using
    the <tt>application/x-www-form-urlencoded</tt> format
    as defined by <a class="info" href="#W3C.REC-html401-19991224">[W3C.REC‑html401‑19991224]<span> (</span><span
            class="info">Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December&nbsp;1999.</span><span>)</span></a>.
    Form Serialization is typically used in HTTP <tt>POST</tt> requests.
</p>

<p>
    The following is a non-normative example of this serialization
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  POST /authorize HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  response_type=code
    &amp;scope=openid
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
</pre>
</div>
<a name="JSONSerialization"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.13.3"></a>

<h3>13.3.&nbsp;
    JSON Serialization</h3>

<p>
    The parameters are serialized into a JSON object structure by adding each
    parameter at the highest structure level. Parameter names and string
    values are represented as JSON strings.
    Numerical values are represented as JSON numbers.
    Boolean values are represented as JSON booleans.
    Omitted parameters and parameters with no value SHOULD be omitted
    from the object and not represented by
    a JSON <tt>null</tt> value, unless otherwise specified.
    A parameter MAY have a JSON object or a JSON array as its value.

</p>

<p>
    The following is a non-normative example of this serialization:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "access_token": "SlAV32hkKG",
   "token_type": "Bearer",
   "expires_in": 3600,
   "refresh_token": "8xLOxBtZp8"
  }
</pre>
</div>
<a name="StringOps"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.14"></a>

<h3>14.&nbsp;
    String Operations</h3>

<p>
    Processing some OpenID Connect messages requires comparing
    values in the messages to known values. For example, the Claim
    Names returned by the UserInfo Endpoint might be compared to
    specific Claim Names such as <tt>sub</tt>. Comparing Unicode strings,
    however, has significant security implications.

</p>

<p>
    Therefore, comparisons between JSON strings and other Unicode
    strings MUST be performed as specified below:

</p>
<ol class="text">
    <li>
        Remove any JSON applied escaping to produce an array of
        Unicode code points.

    </li>
    <li>
        Unicode Normalization <a class="info"
                                 href="#USA15">[USA15]<span> (</span><span
            class="info">Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” 09&nbsp;2009.</span><span>)</span></a>
        MUST NOT
        be applied at any point to either the JSON string or to
        the string it is to be compared against.

    </li>
    <li>
        Comparisons between the two strings MUST be performed as a
        Unicode code point to code point equality comparison.

    </li>
</ol>
<p>

</p>

<p>
    In several places, this specification uses space delimited
    lists of strings. In all such cases, a single ASCII space
    character (0x20) MUST be used as the delimiter.

</p>
<a name="ImplementationConsiderations"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15"></a>

<h3>15.&nbsp;
    Implementation Considerations</h3>

<p>
    This specification defines features used by both Relying Parties and
    OpenID Providers.
    It is expected that some OpenID Providers will require
    static, out-of-band configuration of RPs using them,
    whereas others will support dynamic usage by RPs without
    a pre-established relationship between them.
    For that reason, the mandatory-to-implement features for OPs
    are listed below in two groups:
    the first for all OPs and the second for "Dynamic" OpenID Providers.

</p>
<a name="ServerMTI"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.1"></a>

<h3>15.1.&nbsp;
    Mandatory to Implement Features for All OpenID Providers</h3>

<p>
    All OpenID Providers MUST implement the following features defined in this specification.
    This list augments the set of features that are already listed elsewhere
    as being "REQUIRED" or are described with a "MUST",
    and so is not, by itself, a comprehensive set of implementation requirements for OPs.

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>Signing ID Tokens with RSA SHA-256</dt>
        <dd>

            OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm
            (an <tt>alg</tt> value of
            <tt>RS256</tt>),
            unless the OP only supports returning ID Tokens from the Token Endpoint
            (as is the case for the Authorization Code Flow)
            and only allows Clients to register specifying
            <tt>none</tt> as the requested ID Token signing algorithm.

        </dd>
        <dt>Prompt Parameter</dt>
        <dd>

            OPs MUST support the <tt>prompt</tt> parameter,
            as defined in <a class="info"
                             href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
                class="info">Authorization Endpoint</span><span>)</span></a>, including the specified
            user interface behaviors such as <tt>none</tt>
            and <tt>login</tt>.

        </dd>
        <dt>Display Parameter</dt>
        <dd>

            OPs MUST support the <tt>display</tt> parameter,
            as defined in <a class="info"
                             href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
                class="info">Authorization Endpoint</span><span>)</span></a>.
            (Note that the minimum level of support required for this parameter is
            simply that its use must not result in an error.)

        </dd>
        <dt>Preferred Locales</dt>
        <dd>

            OPs MUST support requests for preferred languages and scripts
            for the user interface and for Claims via the
            <tt>ui_locales</tt> and
            <tt>claims_locales</tt> request parameters,
            as defined in <a class="info"
                             href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
                class="info">Authorization Endpoint</span><span>)</span></a>.
            (Note that the minimum level of support required for these parameters is
            simply to have their use not result in errors.)

        </dd>
        <dt>Authentication Time</dt>
        <dd>

            OPs MUST support returning the time at which the End-User authenticated
            via the <tt>auth_time</tt> Claim, when requested,
            as defined in <a class="info" href="#IDToken">Section&nbsp;2<span> (</span><span
                class="info">ID Token</span><span>)</span></a>.

        </dd>
        <dt>Maximum Authentication Age</dt>
        <dd>

            OPs MUST support enforcing a maximum authentication age
            via the <tt>max_age</tt> parameter,
            as defined in <a class="info"
                             href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
                class="info">Authorization Endpoint</span><span>)</span></a>.

        </dd>
        <dt>Authentication Context Class Reference</dt>
        <dd>

            OPs MUST support requests for specific
            Authentication Context Class Reference values
            via the <tt>acr_values</tt> parameter,
            as defined in <a class="info"
                             href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
                class="info">Authorization Endpoint</span><span>)</span></a>.
            (Note that the minimum level of support required for this parameter is
            simply to have its use not result in an error.)

        </dd>
    </dl>
</blockquote>
<p>

</p>
<a name="DynamicMTI"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.2"></a>

<h3>15.2.&nbsp;
    Mandatory to Implement Features for Dynamic OpenID Providers</h3>

<p>
    In addition to the features listed above,
    OpenID Providers supporting dynamic establishment of relationships with RPs
    that they do not have a pre-configured relationship with
    MUST also implement the following features defined in this and related specifications.

</p>

<p>
</p>
<blockquote class="text">
    <dl>
        <dt>Response Types</dt>
        <dd>

            These OpenID Providers MUST support the
            <tt>id_token</tt> Response Type and
            all that are not Self-Issued OPs MUST also support the
            <tt>code</tt> and
            <tt>id_token&nbsp;token</tt> Response Types.

        </dd>
        <dt>Discovery</dt>
        <dd>

            These OPs MUST support Discovery,
            as defined in
            <a class="info" href="#OpenID.Discovery">OpenID Connect
                Discovery 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November&nbsp;2014.</span><span>)</span></a>
            [OpenID.Discovery].

        </dd>
        <dt>Dynamic Registration</dt>
        <dd>

            These OPs MUST support Dynamic Client Registration,
            as defined in
            <a class="info" href="#OpenID.Registration">OpenID
                Connect Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November&nbsp;2014.</span><span>)</span></a>
            [OpenID.Registration].

        </dd>
        <dt>UserInfo Endpoint</dt>
        <dd>

            All dynamic OPs that issue Access Tokens MUST support the UserInfo Endpoint,
            as defined in <a class="info" href="#UserInfo">Section&nbsp;5.3<span> (</span><span
                class="info">UserInfo Endpoint</span><span>)</span></a>.
            (Self-Issued OPs do not issue Access Tokens.)

        </dd>
        <dt>Public Keys Published as Bare Keys</dt>
        <dd>

            These OPs MUST publish their public keys as bare JWK keys
            (which MAY also be accompanied by X.509 representations of those keys).

        </dd>
        <dt>Request URI</dt>
        <dd>

            These OPs MUST support requests made using a Request Object value
            that is retrieved from a Request URI that is provided
            with the <tt>request_uri</tt> parameter,
            as defined in <a class="info"
                             href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
                class="info">Authorization Endpoint</span><span>)</span></a>.

        </dd>
    </dl>
</blockquote>
<p>

</p>
<a name="DiscoReg"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.3"></a>

<h3>15.3.&nbsp;
    Discovery and Registration</h3>

<p>Some OpenID Connect installations can use a pre-configured set of
    OpenID Providers and/or Relying Parties. In those cases, it might not be
    necessary to support dynamic discovery of information about identities
    or services or dynamic registration of Clients.
</p>

<p>However, if installations choose to support unanticipated
    interactions between Relying Parties and OpenID Providers that do not
    have pre-configured relationships, they SHOULD accomplish this by
    implementing the facilities defined in the <a class="info"
                                                  href="#OpenID.Discovery">OpenID
        Connect Discovery 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November&nbsp;2014.</span><span>)</span></a>
    [OpenID.Discovery] and <a class="info"
                              href="#OpenID.Registration">OpenID
        Connect Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November&nbsp;2014.</span><span>)</span></a>
    [OpenID.Registration]
    specifications.
</p>
<a name="RPMTI"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.4"></a>

<h3>15.4.&nbsp;
    Mandatory to Implement Features for Relying Parties</h3>

<p>
    In general, it is up to Relying Parties which features they use
    when interacting with OpenID Providers.
    However, some choices are dictated by the nature of their OAuth Client,
    such as whether it is a Confidential Client, capable of keeping secrets,
    in which case the Authorization Code Flow may be appropriate,
    or whether it is a Public Client, for instance, a
    User Agent Based Application or a statically registered Native Application,
    in which case the Implicit Flow may be appropriate.

</p>

<p>
    When using OpenID Connect features, those listed as being
    "REQUIRED" or are described with a "MUST" are
    mandatory to implement, when used by a Relying Party.
    Likewise, those features that are described as "OPTIONAL"
    need not be used or supported unless they provide value
    in the particular application context.
    Finally, when interacting with OpenID Providers that support Discovery,
    the OP's Discovery document can be used to dynamically determine
    which OP features are available for use by the RP.

</p>

<p>

</p>
<a name="ImplementationNotes"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.5"></a>

<h3>15.5.&nbsp;
    Implementation Notes</h3>

<a name="CodeNotes"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.5.1"></a>

<h3>15.5.1.&nbsp;
    Authorization Code Implementation Notes</h3>

<p>
    When using the Authorization Code or Hybrid flows,
    an ID Token is returned from the Token Endpoint
    in response to a Token Request using an Authorization Code.
    Some implementations may choose to encode state about
    the ID Token to be returned in the Authorization Code value.
    Others may use the Authorization Code value
    as an index into a database storing this state.

</p>
<a name="NonceNotes"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.5.2"></a>

<h3>15.5.2.&nbsp;
    Nonce Implementation Notes</h3>

<p>
    The <tt>nonce</tt> parameter value needs to include
    per-session state and be unguessable to attackers.
    One method to achieve this for Web Server Clients is to store a cryptographically random value
    as an HttpOnly session cookie and use a cryptographic hash of the value
    as the <tt>nonce</tt> parameter.
    In that case, the <tt>nonce</tt> in the returned
    ID Token is compared to the hash of the session cookie
    to detect ID Token replay by third parties.
    A related method applicable to JavaScript Clients is to store the cryptographically random value
    in HTML5 local storage and use a cryptographic hash of this value.

</p>
<a name="FragmentNotes"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.5.3"></a>

<h3>15.5.3.&nbsp;
    Redirect URI Fragment Handling Implementation Notes</h3>

<p>
    When response parameters are returned in the Redirection URI fragment value,
    the Client needs to have the User Agent parse the fragment encoded values
    and pass them to on to the Client's processing logic for consumption.
    User Agents that have direct access to cryptographic APIs may be able to be
    self-contained, for instance, with all Client code being written in JavaScript.

</p>

<p>
    However, if the Client does not run entirely in the User Agent,
    one way to achieve this
    is to post them to a Web Server Client for validation.

</p>

<p>The following is an example of a JavaScript file that a Client might host at its
    <tt>redirect_uri</tt>. This is loaded by the redirect from
    the Authorization Server. The fragment component is parsed and then sent by <tt>POST</tt> to a URI
    that will validate and use the information received.
</p>

<p>Following is a non-normative example of a
    Redirect URI response:
</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /cb HTTP/1.1
  Host: client.example.org

  HTTP/1.1 200 OK
  Content-Type: text/html

  &lt;script type="text/javascript"&gt;

  // First, parse the query string
  var params = {}, postBody = location.hash.substring(1),
      regex = /([^&amp;=]+)=([^&amp;]*)/g, m;
  while (m = regex.exec(postBody)) {
    params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
  }

  // And send the token over to the server
  var req = new XMLHttpRequest();
  // using POST so query isn't logged
  req.open('POST', 'https://' + window.location.host +
                   '/catch_response', true);
  req.setRequestHeader('Content-Type',
                       'application/x-www-form-urlencoded');

  req.onreadystatechange = function (e) {
    if (req.readyState == 4) {
      if (req.status == 200) {
  // If the response from the POST is 200 OK, perform a redirect
        window.location = 'https://'
          + window.location.host + '/redirect_after_login'
      }
  // if the OAuth response is invalid, generate an error message
      else if (req.status == 400) {
        alert('There was an error processing the token')
      } else {
        alert('Something other than 200 was returned')
      }
    }
  };
  req.send(postBody);
</pre>
</div>
<a name="CompatibilityNotes"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.6"></a>

<h3>15.6.&nbsp;
    Compatibility Notes</h3>

<a name="PreFinalIETFSpecs"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.6.1"></a>

<h3>15.6.1.&nbsp;
    Pre-Final IETF Specifications</h3>

<p>
    Implementers should be aware that
    this specification uses several IETF specifications that are
    not yet final specifications. Those specifications are:
</p>
<ul class="text">
    <li><a class="info" href="#JWT">JSON Web Token (JWT) draft
        -25<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>
        [JWT]
    </li>
    <li><a class="info" href="#JWS">JSON Web Signature (JWS) draft
        -31<span> (</span><span class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>
        [JWS]
    </li>
    <li><a class="info" href="#JWE">JSON Web Encryption (JWE) draft
        -31<span> (</span><span class="info">Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July&nbsp;2014.</span><span>)</span></a>
        [JWE]
    </li>
    <li><a class="info" href="#JWK">JSON Web Key (JWK) draft
        -31<span> (</span><span class="info">Jones, M., “JSON Web Key (JWK),” July&nbsp;2014.</span><span>)</span></a>
        [JWK]
    </li>
    <li><a class="info" href="#JWA">JSON Web Algorithms draft
        -31<span> (</span><span
                class="info">Jones, M., “JSON Web Algorithms (JWA),” July&nbsp;2014.</span><span>)</span></a> [JWA]
    </li>
    <li><a class="info" href="#OAuth.Assertions">Assertion Framework
        for OAuth 2.0 Client Authentication and Authorization Grants draft -17<span> (</span><span class="info">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>
        [OAuth.Assertions]
    </li>
    <li><a class="info" href="#OAuth.JWT">JSON Web Token (JWT)
        Profile for OAuth 2.0 Client Authentication and Authorization Grants draft -10<span> (</span><span class="info">Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July&nbsp;2014.</span><span>)</span></a>
        [OAuth.JWT]
    </li>
</ul>
<p>

</p>

<p>
    While every effort will be made to prevent breaking
    changes to these specifications, should they occur,
    OpenID Connect implementations should continue to use the
    specifically referenced draft versions above in preference
    to the final versions, unless using a possible future
    OpenID Connect profile or specification that
    updates some or all of these references.

</p>
<a name="GoogleIss"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.6.2"></a>

<h3>15.6.2.&nbsp;
    Google "iss" Value</h3>

<p>
    Implementers may want to be aware that,
    as of the time of this writing,
    Google's deployed OpenID Connect implementation issues ID Tokens
    that omit the required <tt>https://</tt>
    scheme prefix from the <tt>iss</tt> (issuer)
    Claim Value.
    Relying Party implementations wishing to work with Google
    will therefore need to have code to work around this,
    until such time as their implementation is updated.
    Any such workaround code should be written in a manner
    that will not break at such point Google adds the
    missing prefix to their issuer values.

</p>
<a name="RelatedSpecs"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.15.7"></a>

<h3>15.7.&nbsp;
    Related Specifications and Implementer's Guides</h3>

<p>
    These related OPTIONAL specifications MAY be used in
    combination with this specification to provide additional functionality:

</p>
<ul class="text">
    <li>
        <a class="info" href="#OpenID.Discovery">OpenID Connect
            Discovery 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November&nbsp;2014.</span><span>)</span></a>
        [OpenID.Discovery] -
        Defines how Relying Parties dynamically discover information about OpenID Providers

    </li>
    <li>
        <a class="info" href="#OpenID.Registration">OpenID Connect
            Dynamic Client Registration 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November&nbsp;2014.</span><span>)</span></a>
        [OpenID.Registration] -
        Defines how Relying Parties dynamically register with OpenID Providers

    </li>
    <li>
        <a class="info" href="#OpenID.Session">OpenID Connect
            Session Management 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Session Management 1.0,” November&nbsp;2014.</span><span>)</span></a>
        [OpenID.Session] -
        Defines how to manage OpenID Connect sessions, including logout functionality

    </li>
    <li>
        <a class="info" href="#OAuth.Post">OAuth 2.0 Form Post
            Response Mode<span> (</span><span class="info">Jones, M. and B. Campbell, “OAuth 2.0 Form Post Response Mode,” February&nbsp;2014.</span><span>)</span></a>
        [OAuth.Post] -
        Defines how to return OAuth 2.0 Authorization Response parameters
        (including OpenID Connect Authentication Response parameters)
        using HTML form values that are auto-submitted by the User Agent
        using HTTP <tt>POST</tt>

    </li>
</ul>
<p>

</p>

<p>
    These implementer's guides are intended to serve as self-contained references
    for implementers of basic Web-based Relying Parties:

</p>
<ul class="text">
    <li><a class="info" href="#OpenID.Basic">OpenID Connect Basic
        Client Implementer's Guide 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Implementer's Guide 1.0,” November&nbsp;2014.</span><span>)</span></a>
        [OpenID.Basic] -
        Implementer's guide containing a subset of this specification
        that is intended for use by basic
        Web-based Relying Parties using the
        OAuth Authorization Code Flow
    </li>
    <li><a class="info" href="#OpenID.Implicit">OpenID Connect
        Implicit Client Implementer's Guide 1.0<span> (</span><span class="info">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Implicit Client Implementer's Guide 1.0,” November&nbsp;2014.</span><span>)</span></a>
        [OpenID.Implicit] -
        Implementer's guide containing a subset of this specification
        that is intended for use by basic
        Web-based Relying Parties using the
        OAuth Implicit Flow
    </li>
</ul>
<p>

</p>
<a name="Security"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16"></a>

<h3>16.&nbsp;
    Security Considerations</h3>

<p>
    This specification references the security considerations defined in
    Section 10 of <a class="info" href="#RFC6749">OAuth
    2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749], and
    Section 5 of <a class="info" href="#RFC6750">OAuth 2.0 Bearer
    Token Usage<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6750].
    Furthermore, the <a class="info" href="#RFC6819">OAuth 2.0
    Threat Model and Security
    Considerations<span> (</span><span class="info">Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January&nbsp;2013.</span><span>)</span></a>
    [RFC6819] specification provides an extensive list of threats and controls
    that apply to this specification as well,
    given that it is based upon OAuth 2.0.
    <a class="info" href="#ISO29115">ISO/IEC
        29115<span> (</span><span class="info">International Organization for Standardization, “ISO/IEC 29115:2013 -- 	  Information technology - Security techniques - Entity authentication 	  assurance framework,” March&nbsp;2013.</span><span>)</span></a>
    [ISO29115]
    also provides threats and controls that
    implementers need to take into account.
    Implementers are highly advised to
    read these references in detail and apply the countermeasures described therein.

</p>

<p>
    In addition, the following list of attack vectors and remedies are
    also considered.

</p>
<a name="RequestDisclosure"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.1"></a>

<h3>16.1.&nbsp;
    Request Disclosure</h3>

<p>If appropriate measures are not taken, a request might be disclosed to
    an attacker, posing security and privacy threats.
</p>

<p>In addition to what is stated in Section 5.1.1 of <a class="info"
                                                        href="#RFC6819">[RFC6819]<span> (</span><span
        class="info">Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January&nbsp;2013.</span><span>)</span></a>,
    this standard provides a way to provide the confidentiality of the request
    end to end through the
    use of <tt>request</tt> or <tt>request_uri</tt>
    parameters, where the content of the <tt>request</tt>
    is an encrypted JWT with the appropriate key and cipher.
    This protects even against a compromised User Agent
    in the case of indirect request.
</p>
<a name="ServerMasquerading"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.2"></a>

<h3>16.2.&nbsp;
    Server Masquerading</h3>

<p>A malicious Server might masquerade as the legitimate server
    using various means. To detect such an attack, the Client needs to authenticate
    the server.
</p>

<p>In addition to what is stated in Section 5.1.2 of <a class="info"
                                                        href="#RFC6819">[RFC6819]<span> (</span><span
        class="info">Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January&nbsp;2013.</span><span>)</span></a>,
    this standard provides a way to authenticate the Server through either the
    use of Signed or Encrypted JWTs
    with an appropriate key and cipher.
</p>
<a name="TokenManufacture"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.3"></a>

<h3>16.3.&nbsp;
    Token Manufacture/Modification</h3>

<p>
    An Attacker might generate a bogus token or modify the token contents
    (such as Claims values or the signature)
    of an existing parseable token, causing the RP to grant
    inappropriate access to the Client. For example, an Attacker might modify
    the parseable token to extend the validity period; a Client might modify the
    parseable token to have access to information that they should not be able to view.

</p>

<p>There are two ways to mitigate this attack:
</p>

<p>
</p>
<ol class="text">
    <li>The token can be digitally signed by the OP. The Relying
        Party SHOULD validate the digital signature to verify that it was
        issued by a legitimate OP.
    </li>
    <li>The token can be sent over a protected channel such as TLS.
        See <a class="info" href="#TLSRequirements">Section&nbsp;16.17<span> (</span><span
                class="info">TLS Requirements</span><span>)</span></a> for more information on using TLS.
        In this specification, the token is always sent over a TLS protected channel.
        Note however, that this measure is only a defense against third party attackers
        and is not applicable to the case where the Client is the attacker.
    </li>
</ol>
<p>

</p>
<a name="AccessTokenDisclosure"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.4"></a>

<h3>16.4.&nbsp;
    Access Token Disclosure</h3>

<p>
    Access Tokens are credentials used to access Protected
    Resources, as defined in Section 1.4 of
    <a class="info" href="#RFC6749">OAuth 2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749]. Access Tokens represent
    an End-User's authorization and MUST NOT be exposed to
    unauthorized parties.

</p>
<a name="ResponseDisclosure"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.5"></a>

<h3>16.5.&nbsp;
    Server Response Disclosure</h3>

<p>
    The server response might contain authentication data and Claims
    that include sensitive Client information. Disclosure of the
    response contents can make the Client vulnerable to other types of
    attacks.

</p>

<p>
    The server response disclosure can be mitigated in the following two
    ways:
</p>
<ol class="text">
    <li>Using the <tt>code</tt> Response Type.
        The response is sent over a TLS protected
        channel, where the Client is authenticated by the
        <tt>client_id</tt> and
        <tt>client_secret</tt>.
    </li>
    <li>For other Response Types,
        the signed response can be encrypted with the Client's
        public key or a shared secret as an encrypted JWT
        with an appropriate key and cipher.
    </li>
</ol>
<p>

</p>
<a name="ServerResponseRepudiation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.6"></a>

<h3>16.6.&nbsp;
    Server Response Repudiation</h3>

<p>A response might be repudiated by the server if the proper mechanisms are not in place.
    For example, if a Server does not digitally sign a response, the Server can claim that it was not
    generated through the services of the Server.
</p>

<p>To mitigate this threat, the response MAY be digitally signed by
    the Server using a key that supports non-repudiation. The Client SHOULD validate
    the digital signature to verify that it was issued by a legitimate
    Server and its integrity is intact.
</p>
<a name="RequestRepudation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.7"></a>

<h3>16.7.&nbsp;
    Request Repudiation</h3>

<p>Since it is possible for a
    compromised or malicious Client to send a request to the wrong party,
    a Client that was authenticated
    using only a bearer token can repudiate any transaction.

</p>

<p>To mitigate this threat, the Server MAY require that the
    request be digitally signed by
    the Client using a key that supports non-repudiation.
    The Server SHOULD validate
    the digital signature to verify that it was issued by a legitimate
    Client and the integrity is intact.
</p>
<a name="AccessTokenRedirect"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.8"></a>

<h3>16.8.&nbsp;
    Access Token Redirect</h3>

<p>An Attacker uses the Access Token generated for one resource to
    obtain access to a second resource.

</p>

<p>To mitigate this threat, the Access Token SHOULD be audience
    and scope restricted. One way of implementing it is to include
    the identifier of the resource for whom it was generated as audience.
    The resource verifies that
    incoming tokens include its identifier as the audience of the
    token.
</p>
<a name="TokenReuse"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.9"></a>

<h3>16.9.&nbsp;
    Token Reuse</h3>

<p>An Attacker attempts to use a one-time use token such as
    an Authorization Code that has already
    been used once with the intended Resource.
    To mitigate this threat, the token SHOULD include a timestamp
    and a short validity lifetime.
    The Relying Party then checks the timestamp and lifetime values
    to ensure that the token is currently valid.
</p>

<p>Alternatively, the server MAY record the state of the use of
    the token and check the status for each request.
</p>
<a name="AuthCodeCapture"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.10"></a>

<h3>16.10.&nbsp;
    Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)</h3>

<p>In addition to the attack patterns described in
    Section 4.4.1.1 of <a class="info"
                          href="#RFC6819">[RFC6819]<span> (</span><span
            class="info">Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January&nbsp;2013.</span><span>)</span></a>,
    an Authorization Code can be captured in the User Agent where the TLS
    session is terminated if the User Agent is infected by malware.
    However, capturing it is not useful as long as either
    Client Authentication or an encrypted response is used.

</p>
<a name="TokenSubstitution"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.11"></a>

<h3>16.11.&nbsp;
    Token Substitution</h3>

<p>
    Token Substitution is a class of attacks in which a malicious user
    swaps various tokens, including swapping an Authorization Code for
    a legitimate user with another token that the attacker has.
    One means of accomplishing this is for the attacker to copy
    a token out one session and use it in an HTTP message for
    a different session, which is easy to do when the token is
    available to the browser; this is known as the "cut and paste" attack.

</p>

<p>
    The Implicit Flow of <a class="info" href="#RFC6749">OAuth
    2.0<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749]
    is not designed to mitigate this risk. In Section 10.16,
    it normatively requires that any use of the authorization
    process as a form of delegated End-User authentication to the
    Client MUST NOT use the Implicit Flow without employing
    additional security mechanisms that enable the Client to
    determine whether the ID Token and Access Token were issued for its use.

</p>

<p>
    In OpenID Connect, this is mitigated through mechanisms
    provided through the ID Token. The ID Token is a signed
    security token that provides Claims such as
    <tt>iss</tt> (issuer),
    <tt>sub</tt> (subject),
    <tt>aud</tt> (audience),
    <tt>azp</tt> (authorized party),
    <tt>at_hash</tt> (access token hash), and
    <tt>c_hash</tt> (code hash). Using the ID Token,
    the Client is capable of detecting the Token Substitution Attack.

</p>

<p>
    The <tt>c_hash</tt> in the ID Token enables
    Clients to prevent Authorization Code substitution.
    The <tt>at_hash</tt> in the ID Token enables
    Clients to prevent Access Token substitution.

</p>

<p>
    Also, a malicious user may attempt to impersonate a more
    privileged user by subverting the communication channel
    between the Authorization Endpoint and Client, or the Token Endpoint
    and Client, for example by swapping the Authorization Code
    or reordering the messages, to convince the Token Endpoint
    that the attacker's authorization grant corresponds to a grant
    sent on behalf of a more privileged user.

</p>

<p>
    For the HTTP binding defined by this specification, the
    responses to Token Requests are bound to the corresponding
    requests by message order in HTTP, as both the response
    containing the token and requests are protected by TLS, which
    will detect and prevent packet reordering.

</p>

<p>
    When designing another binding of this specification to a
    protocol incapable of strongly binding Token Endpoint
    requests to responses, additional mechanisms to
    address this issue MUST be utilized. One such mechanism could
    be to include an ID Token with a <tt>c_hash</tt>
    Claim in the token request and response.

</p>
<a name="TimingAttack"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.12"></a>

<h3>16.12.&nbsp;
    Timing Attack</h3>

<p>A timing attack enables the attacker to
    obtain an unnecessary large amount of information through the elapsed time
    differences in the code paths taken by successful and unsuccessful decryption operations or
    successful and unsuccessful signature validation of a message.
    It can be used to reduce the effective key length of the
    cipher used.
</p>

<p>Implementations SHOULD NOT terminate the validation process
    at the instant of the finding an error but SHOULD continue
    running until all the octets have been processed to avoid this attack.
</p>
<a name="OtherCryptoAttacks"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.13"></a>

<h3>16.13.&nbsp;
    Other Crypto Related Attacks</h3>

<p>There are various crypto related attacks possible depending on the
    method used for encryption and signature / integrity checking.
    Implementers need to consult the Security Considerations
    for the <a class="info" href="#JWT">JWT<span> (</span><span
            class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>
    [JWT] specification and
    specifications that it references
    to avoid the vulnerabilities
    identified in these specifications.

</p>
<a name="SigningOrder"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.14"></a>

<h3>16.14.&nbsp;
    Signing and Encryption Order</h3>

<p>
    Signatures over encrypted text are not considered valid
    in many jurisdictions.
    Therefore, for integrity and non-repudiation,
    this specification requires signing
    the plain text JSON Claims, when signing is performed.
    If both signing and encryption are desired, it is performed on
    the JWS containing the signed Claims,
    with the result being a Nested JWT, as specified in <a class="info"
                                                           href="#JWT">[JWT]<span> (</span><span
        class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>.
    Note that since all JWE encryption algorithms provide integrity protection,
    there is no need to separately sign the encrypted content.

</p>
<a name="IssuerIdentifier"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.15"></a>

<h3>16.15.&nbsp;
    Issuer Identifier</h3>

<p>OpenID Connect supports multiple Issuers per Host and Port combination.
    The issuer returned by discovery MUST exactly match the value of
    <tt>iss</tt> in the ID Token.
</p>

<p>
    OpenID Connect treats the path component of any Issuer URI as
    being part of the Issuer Identifier. For instance, the subject
    "1234" with an Issuer Identifier of "https://example.com" is not
    equivalent to the subject "1234" with an Issuer Identifier of
    "https://example.com/sales".

</p>

<p>
    It is RECOMMENDED that only a single Issuer per host be used.
    However, if a host supports multiple tenants,
    multiple Issuers for that host may be needed.

</p>
<a name="ImplicitFlowThreats"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.16"></a>

<h3>16.16.&nbsp;
    Implicit Flow Threats</h3>

<p>In the Implicit Flow, the Access Token is returned in the
    fragment component of the Client's <tt>redirect_uri</tt> through HTTPS, thus it is
    protected between the OP and the User Agent, and between the User Agent and the
    RP. The only place it can be captured is the User Agent where the
    TLS session is terminated, which is possible if the User Agent is
    infected by malware or under the control of a malicious party.
</p>
<a name="TLSRequirements"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.17"></a>

<h3>16.17.&nbsp;
    TLS Requirements</h3>

<p>
    Implementations MUST support TLS.
    Which version(s) ought to be implemented will vary over
    time, and depend on the widespread deployment and known
    security vulnerabilities at the time of implementation.
    At the time of this writing,
    TLS version 1.2 <a class="info" href="#RFC5246">[RFC5246]<span> (</span><span
        class="info">Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August&nbsp;2008.</span><span>)</span></a>
    is the most recent version, but has very limited actual
    deployment, and might not be readily available in
    implementation toolkits.
    TLS version 1.0 <a class="info" href="#RFC2246">[RFC2246]<span> (</span><span
        class="info">Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January&nbsp;1999.</span><span>)</span></a>
    is the most widely deployed version, and will give the
    broadest interoperability.

</p>

<p>
    To protect against information disclosure and tampering,
    confidentiality protection MUST be applied using TLS
    with a ciphersuite that provides confidentiality and
    integrity protection.

</p>

<p>
    Whenever TLS is used, a TLS server certificate check
    MUST be performed, per <a class="info" href="#RFC6125">RFC
    6125<span> (</span><span class="info">Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March&nbsp;2011.</span><span>)</span></a>
    [RFC6125].

</p>
<a name="TokenLifetime"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.18"></a>

<h3>16.18.&nbsp;
    Lifetimes of Access Tokens and Refresh Tokens</h3>

<p>Access Tokens might not be revocable by the Authorization Server.
    Access Token lifetimes SHOULD therefore be kept to single use or
    very short lifetimes.
</p>

<p>
    If ongoing access to the UserInfo Endpoint or other Protected Resources is required,
    a Refresh Token can be used. The Client can then exchange the Refresh Token at
    the Token Endpoint for a fresh short-lived Access Token that can be used to
    access the resource.

</p>

<p>
    The Authorization Server SHOULD clearly identify long-term grants to the User
    during Authorization.
    The Authorization Server SHOULD provide a mechanism for the End-User to revoke
    Access Tokens and Refresh Tokens granted to a Client.

</p>
<a name="SymmetricKeyEntropy"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.19"></a>

<h3>16.19.&nbsp;
    Symmetric Key Entropy</h3>

<p>
    In <a class="info"
          href="#Signing">Section&nbsp;10.1<span> (</span><span
        class="info">Signing</span><span>)</span></a> and <a class="info"
                                                             href="#Encryption">Section&nbsp;10.2<span> (</span><span
        class="info">Encryption</span><span>)</span></a>, keys are derived
    from the <tt>client_secret</tt> value.
    Thus, when used with symmetric signing or encryption operations,
    <tt>client_secret</tt> values MUST contain
    sufficient entropy to generate cryptographically strong keys.
    Also, <tt>client_secret</tt> values MUST also contain
    at least the minimum of number of octets required for MAC keys for the
    particular algorithm used.
    So for instance, for <tt>HS256</tt>, the
    <tt>client_secret</tt> value MUST contain
    at least 32 octets (and almost certainly SHOULD contain more,
    since <tt>client_secret</tt> values are
    likely to use a restricted alphabet).

</p>
<a name="NeedForSignedRequests"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.20"></a>

<h3>16.20.&nbsp;
    Need for Signed Requests</h3>

<p>
    In some situations, Clients might need to use signed requests to ensure that
    the desired request parameters are delivered to the OP without having
    been tampered with. For instance, the <tt>max_age</tt>
    and <tt>acr_values</tt> provide more assurance about
    the nature of the authentication performed when delivered in signed requests.

</p>
<a name="NeedForEncryptedRequests"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.16.21"></a>

<h3>16.21.&nbsp;
    Need for Encrypted Requests</h3>

<p>
    In some situations, knowing the contents of an OpenID Connect request can,
    in and of itself, reveal sensitive information about the End-User.
    For instance, knowing that the Client is requesting a particular Claim or
    that it is requesting that a particular authentication method be used
    can reveal sensitive information about the End-User.
    OpenID Connect enables requests to be encrypted to the OpenID Provider
    to prevent such potentially sensitive information from being revealed.

</p>
<a name="Privacy"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.17"></a>

<h3>17.&nbsp;
    Privacy Considerations</h3>

<a name="PII"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.17.1"></a>

<h3>17.1.&nbsp;
    Personally Identifiable Information</h3>

<p>The UserInfo Response typically contains Personally Identifiable
    Information (PII). As such, End-User consent for the release of the information
    for the specified purpose should be obtained at or prior to the
    authorization time in accordance with relevant regulations. The purpose
    of use is typically registered in association with the <tt>redirect_uris</tt>.
</p>

<p>Only necessary UserInfo data should be stored at the Client and the
    Client SHOULD associate the received data with the purpose of use
    statement.
</p>
<a name="AccessMonitoring"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.17.2"></a>

<h3>17.2.&nbsp;
    Data Access Monitoring</h3>

<p>
    The Resource Server SHOULD make End-Users' UserInfo access logs
    available to them so that they can monitor who accessed their data.

</p>
<a name="Correlation"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.17.3"></a>

<h3>17.3.&nbsp;
    Correlation</h3>

<p>To protect the End-User from a possible correlation among Clients, the
    use of a Pairwise Pseudonymous Identifier (PPID) as the
    <tt>sub</tt> (subject) SHOULD be considered.
</p>
<a name="OfflineAccessPrivacy"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.17.4"></a>

<h3>17.4.&nbsp;
    Offline Access</h3>

<p>
    Offline access enables access to Claims when the user is not present,
    posing greater privacy risk than the Claims transfer when the user is present.
    Therefore, it is prudent to obtain explicit consent for
    offline access to resources.
    This specification mandates the use of the <tt>prompt</tt>
    parameter to obtain consent unless it is already known that the
    request complies with the conditions for processing the request in each jurisdiction.

</p>

<p>
    When an Access Token is returned via the User Agent
    using the Implicit Flow or Hybrid Flow, there is
    a greater risk of it being exposed to an attacker, who could
    later use it to access the UserInfo endpoint.
    If the Access Token does not enable offline access and the server
    can differentiate whether the Client request has been made
    offline or online, the risk will be substantially reduced.
    Therefore, this specification mandates ignoring
    the offline access request when the Access Token is
    transmitted through the User Agent.
    Note that differentiating between online and offline access
    from the server can be difficult especially for native clients.
    The server may well have to rely on heuristics.
    Also, the risk of exposure for the Access Token delivered
    through the User Agent for the Response Types of
    <tt>code&nbsp;token</tt> and
    <tt>token</tt> is the same.
    Thus, the implementations should be prepared to detect
    whether the Access Token was issued through the User Agent
    or directly from the Token Endpoint and deny offline access
    if the token was issued through the User Agent.

</p>

<p>
    Note that although these provisions require an explicit
    consent dialogue through the <tt>prompt</tt> parameter,
    the mere fact that the user pressed an "accept" button etc.,
    might not constitute a valid consent.
    Developers should be aware that for the act of consent to
    be valid, typically, the impact of the terms have to be
    understood by the End-User, the consent must be freely given
    and not forced (i.e., other options have to be available),
    and the terms must fair and equitable.
    In general, it is advisable for the service to follow the
    required privacy principles in each jurisdiction and rely on
    other conditions for processing the request than simply explicit consent,
    as online self-service "explicit consent" often does not
    form a valid consent in some jurisdictions.

</p>
<a name="IANA"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.18"></a>

<h3>18.&nbsp;
    IANA Considerations</h3>

<a name="ClaimsRegistry"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.18.1"></a>

<h3>18.1.&nbsp;
    JSON Web Token Claims Registration</h3>

<p>
    This specification registers the Claims defined in
    <a class="info"
       href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> and <a class="info"
                                                                         href="#IDToken">Section&nbsp;2<span> (</span><span
        class="info">ID Token</span><span>)</span></a> in the IANA
    JSON Web Token Claims registry
    defined in <a class="info" href="#JWT">[JWT]<span> (</span><span
        class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July&nbsp;2014.</span><span>)</span></a>.

</p>
<a name="ClaimsContents"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.18.1.1"></a>

<h3>18.1.1.&nbsp;
    Registry Contents</h3>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>name</tt>

    </li>
    <li>
        Claim Description: Full name

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>given_name</tt>

    </li>
    <li>
        Claim Description: Given name(s) or first name(s)

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>family_name</tt>

    </li>
    <li>
        Claim Description: Surname(s) or last name(s)

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>middle_name</tt>

    </li>
    <li>
        Claim Description: Middle name(s)

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>nickname</tt>

    </li>
    <li>
        Claim Description: Casual name

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>preferred_username</tt>

    </li>
    <li>
        Claim Description: Shorthand name by which the End-User wishes to be referred to

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>profile</tt>

    </li>
    <li>
        Claim Description: Profile page URL

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>picture</tt>

    </li>
    <li>
        Claim Description: Profile picture URL

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>website</tt>

    </li>
    <li>
        Claim Description: Web page or blog URL

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>email</tt>

    </li>
    <li>
        Claim Description: Preferred e-mail address

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>email_verified</tt>

    </li>
    <li>
        Claim Description: True if the e-mail address has been verified; otherwise false

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>gender</tt>

    </li>
    <li>
        Claim Description: Gender

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>birthdate</tt>

    </li>
    <li>
        Claim Description: Birthday

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>zoneinfo</tt>

    </li>
    <li>
        Claim Description: Time zone

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>locale</tt>

    </li>
    <li>
        Claim Description: Locale

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>phone_number</tt>

    </li>
    <li>
        Claim Description: Preferred telephone number

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>phone_number_verified</tt>

    </li>
    <li>
        Claim Description: True if the phone number has been verified; otherwise false

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>address</tt>

    </li>
    <li>
        Claim Description: Preferred postal address

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>updated_at</tt>

    </li>
    <li>
        Claim Description: Time the information was last updated

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#StandardClaims">Section&nbsp;5.1<span> (</span><span
            class="info">Standard Claims</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>azp</tt>

    </li>
    <li>
        Claim Description: Authorized party - the party to which the ID Token was issued

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info" href="#IDToken">Section&nbsp;2<span> (</span><span
            class="info">ID Token</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>nonce</tt>

    </li>
    <li>
        Claim Description: Value used to associate a Client session with an ID Token

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info" href="#IDToken">Section&nbsp;2<span> (</span><span
            class="info">ID Token</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>auth_time</tt>

    </li>
    <li>
        Claim Description: Time when the authentication occurred

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info" href="#IDToken">Section&nbsp;2<span> (</span><span
            class="info">ID Token</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>at_hash</tt>

    </li>
    <li>
        Claim Description: Access Token hash value

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info" href="#IDToken">Section&nbsp;2<span> (</span><span
            class="info">ID Token</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>c_hash</tt>

    </li>
    <li>
        Claim Description: Code hash value

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#HybridIDToken">Section&nbsp;3.3.2.11<span> (</span><span
            class="info">ID Token</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>acr</tt>

    </li>
    <li>
        Claim Description: Authentication Context Class Reference

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info" href="#IDToken">Section&nbsp;2<span> (</span><span
            class="info">ID Token</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>amr</tt>

    </li>
    <li>
        Claim Description: Authentication Methods References

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info" href="#IDToken">Section&nbsp;2<span> (</span><span
            class="info">ID Token</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>
        Claim Name: <tt>sub_jwk</tt>

    </li>
    <li>
        Claim Description: Public key used to check the signature of an ID Token

    </li>
    <li>
        Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net

    </li>
    <li>
        Specification Document(s): <a class="info"
                                      href="#SelfIssuedResponse">Section&nbsp;7.4<span> (</span><span
            class="info">Self-Issued OpenID Provider Response</span><span>)</span></a> of this document

    </li>
</ul>
<p>

</p>
<a name="OAuthParametersRegistry"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.18.2"></a>

<h3>18.2.&nbsp;
    OAuth Parameters Registration</h3>

<p>
    This specification registers the following parameters
    in the IANA
    OAuth Parameters registry
    defined in <a class="info" href="#RFC6749">RFC
    6749<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749].

</p>
<a name="ParametersContents"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.18.2.1"></a>

<h3>18.2.1.&nbsp;
    Registry Contents</h3>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>nonce</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
            class="info">Authorization Endpoint</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>display</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
            class="info">Authorization Endpoint</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>prompt</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
            class="info">Authorization Endpoint</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>max_age</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
            class="info">Authorization Endpoint</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>ui_locales</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
            class="info">Authorization Endpoint</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>claims_locales</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#ClaimsLanguagesAndScripts">Section&nbsp;5.2<span> (</span><span
            class="info">Claims Languages and Scripts</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>id_token_hint</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
            class="info">Authorization Endpoint</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>login_hint</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
            class="info">Authorization Endpoint</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>acr_values</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthorizationEndpoint">Section&nbsp;3.1.2<span> (</span><span
            class="info">Authorization Endpoint</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>claims</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#ClaimsParameter">Section&nbsp;5.5<span> (</span><span
            class="info">Requesting Claims using the "claims" Request Parameter</span><span>)</span></a> of this
        document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>registration</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#RegistrationParameter">Section&nbsp;7.2.1<span> (</span><span
            class="info">Providing Information with the "registration" Request Parameter</span><span>)</span></a> of
        this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>request</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#JWTRequests">Section&nbsp;6<span> (</span><span
            class="info">Passing Request Parameters as JWTs</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>request_uri</tt>
    </li>
    <li>Parameter usage location: Authorization Request
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#JWTRequests">Section&nbsp;6<span> (</span><span
            class="info">Passing Request Parameters as JWTs</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Parameter name: <tt>id_token</tt>
    </li>
    <li>Parameter usage location: Authorization Response,
        Access Token Response
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#TokenResponse">Section&nbsp;3.1.3.3<span> (</span><span
            class="info">Successful Token Response</span><span>)</span></a> of this document
    </li>
    <li>Related information: None
    </li>
</ul>
<p>

</p>
<a name="OAuthErrorRegistry"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.18.3"></a>

<h3>18.3.&nbsp;
    OAuth Extensions Error Registration</h3>

<p>
    This specification registers the following errors
    in the IANA
    OAuth Extensions Error registry
    defined in <a class="info" href="#RFC6749">RFC
    6749<span> (</span><span
            class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” October&nbsp;2012.</span><span>)</span></a>
    [RFC6749].

</p>
<a name="ErrorContents"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.18.3.1"></a>

<h3>18.3.1.&nbsp;
    Registry Contents</h3>

<p>
</p>
<ul class="text">
    <li>Error name: <tt>interaction_required</tt>
    </li>
    <li>Error usage location: Authorization Endpoint
    </li>
    <li>Related protocol extension: OpenID Connect
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
            class="info">Authentication Error Response</span><span>)</span></a> of this document
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Error name: <tt>login_required</tt>
    </li>
    <li>Error usage location: Authorization Endpoint
    </li>
    <li>Related protocol extension: OpenID Connect
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
            class="info">Authentication Error Response</span><span>)</span></a> of this document
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Error name: <tt>account_selection_required</tt>
    </li>
    <li>Error usage location: Authorization Endpoint
    </li>
    <li>Related protocol extension: OpenID Connect
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
            class="info">Authentication Error Response</span><span>)</span></a> of this document
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Error name: <tt>consent_required</tt>
    </li>
    <li>Error usage location: Authorization Endpoint
    </li>
    <li>Related protocol extension: OpenID Connect
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
            class="info">Authentication Error Response</span><span>)</span></a> of this document
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Error name: <tt>invalid_request_uri</tt>
    </li>
    <li>Error usage location: Authorization Endpoint
    </li>
    <li>Related protocol extension: OpenID Connect
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
            class="info">Authentication Error Response</span><span>)</span></a> of this document
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Error name: <tt>invalid_request_object</tt>
    </li>
    <li>Error usage location: Authorization Endpoint
    </li>
    <li>Related protocol extension: OpenID Connect
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
            class="info">Authentication Error Response</span><span>)</span></a> of this document
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Error name: <tt>request_not_supported</tt>
    </li>
    <li>Error usage location: Authorization Endpoint
    </li>
    <li>Related protocol extension: OpenID Connect
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
            class="info">Authentication Error Response</span><span>)</span></a> of this document
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Error name: <tt>request_uri_not_supported</tt>
    </li>
    <li>Error usage location: Authorization Endpoint
    </li>
    <li>Related protocol extension: OpenID Connect
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
            class="info">Authentication Error Response</span><span>)</span></a> of this document
    </li>
</ul>
<p>

</p>

<p>
</p>
<ul class="text">
    <li>Error name: <tt>registration_not_supported</tt>
    </li>
    <li>Error usage location: Authorization Endpoint
    </li>
    <li>Related protocol extension: OpenID Connect
    </li>
    <li>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
    </li>
    <li>Specification document(s): <a class="info"
                                      href="#AuthError">Section&nbsp;3.1.2.6<span> (</span><span
            class="info">Authentication Error Response</span><span>)</span></a> of this document
    </li>
</ul>
<p>

</p>
<a name="rfc.references"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.19"></a>

<h3>19.&nbsp;
    References</h3>

<a name="rfc.references1"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<h3>19.1.&nbsp;Normative References</h3>
<table width="99%" border="0">
    <tbody>
    <tr>
        <td class="author-text" valign="top"><a name="CORS">[CORS]</a></td>
        <td class="author-text">Opera Software ASA, “<a href="http://www.w3.org/TR/access-control/">Cross-Origin
            Resource Sharing</a>,” July&nbsp;2010.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="E.164">[E.164]</a></td>
        <td class="author-text">International Telecommunication Union, “<a
                href="http://www.itu.int/rec/T-REC-E.164-201011-I/en">E.164: The international public telecommunication
            numbering plan</a>,” 2010.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="IANA.Language">[IANA.Language]</a></td>
        <td class="author-text">Internet Assigned Numbers Authority (IANA), “<a
                href="http://www.iana.org/assignments/language-subtag-registry">Language Subtag Registry</a>,” 2005.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="ISO29115">[ISO29115]</a></td>
        <td class="author-text">International Organization for Standardization, “<a
                href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45138">ISO/IEC
            29115:2013 --
            Information technology - Security techniques - Entity authentication
            assurance framework</a>,” ISO/IEC&nbsp;29115, March&nbsp;2013.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="ISO3166-1">[ISO3166-1]</a></td>
        <td class="author-text">International Organization for
            Standardization, “<a href="http://www.w3.org/WAI/ER/IG/ert/iso639.htm">ISO 3166-1:1997. Codes for the
                representation of names of
                countries and their subdivisions -- Part 1: Country codes</a>,” 1997.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="ISO639-1">[ISO639-1]</a></td>
        <td class="author-text">International Organization for
            Standardization, “ISO 639-1:2002. Codes for the representation of names of
            languages -- Part 1: Alpha-2 code,” 2002.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="ISO8601-2004">[ISO8601-2004]</a></td>
        <td class="author-text">International Organization for
            Standardization, “ISO 8601:2004. Data elements and interchange formats - Information interchange -
            Representation of dates and times,” 2004.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="JWA">[JWA]</a></td>
        <td class="author-text">Jones, M., “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms">JSON
            Web Algorithms (JWA)</a>,” draft-ietf-jose-json-web-algorithms (work in progress), July&nbsp;2014 (<a
                href="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="JWE">[JWE]</a></td>
        <td class="author-text">Jones, M., Rescorla, E., and J. Hildebrand, “<a
                href="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption">JSON Web Encryption (JWE)</a>,”
            draft-ietf-jose-json-web-encryption (work in progress), July&nbsp;2014 (<a
                    href="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-31">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="JWK">[JWK]</a></td>
        <td class="author-text">Jones, M., “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-key">JSON Web
            Key (JWK)</a>,” draft-ietf-jose-json-web-key (work in progress), July&nbsp;2014 (<a
                href="http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="JWS">[JWS]</a></td>
        <td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a
                href="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature">JSON Web Signature (JWS)</a>,”
            draft-ietf-jose-json-web-signature (work in progress), July&nbsp;2014 (<a
                    href="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-31">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="JWT">[JWT]</a></td>
        <td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a
                href="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token">JSON Web Token (JWT)</a>,”
            draft-ietf-oauth-json-web-token (work in progress), July&nbsp;2014 (<a
                    href="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OAuth.Assertions">[OAuth.Assertions]</a></td>
        <td class="author-text">Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “<a
                href="http://tools.ietf.org/html/draft-ietf-oauth-assertions">Assertion Framework for OAuth 2.0 Client
            Authentication and Authorization Grants</a>,” draft-ietf-oauth-assertions (work in progress), July&nbsp;2014
            (<a href="http://tools.ietf.org/html/draft-ietf-oauth-assertions-17">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OAuth.JWT">[OAuth.JWT]</a></td>
        <td class="author-text">Jones, M., Campbell, B., and C. Mortimore, “<a
                href="http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer">JSON Web Token (JWT) Profile for OAuth 2.0
            Client Authentication and Authorization Grants</a>,” draft-ietf-oauth-jwt-bearer (work in progress), July&nbsp;2014
            (<a href="http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OAuth.Responses">[OAuth.Responses]</a></td>
        <td class="author-text">de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “<a
                href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html">OAuth 2.0 Multiple Response
            Type Encoding Practices</a>,” February&nbsp;2014.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OpenID.Discovery">[OpenID.Discovery]</a></td>
        <td class="author-text">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “<a
                href="http://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery 1.0</a>,”
            November&nbsp;2014.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OpenID.Registration">[OpenID.Registration]</a></td>
        <td class="author-text">Sakimura, N., Bradley, J., and M. Jones, “<a
                href="http://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Dynamic Client
            Registration 1.0</a>,” November&nbsp;2014.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
        <td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a
                href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,”
            BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a
                    href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a
                    href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC2246">[RFC2246]</a></td>
        <td class="author-text"><a href="mailto:tdierks@certicom.com">Dierks, T.</a> and <a
                href="mailto:callen@certicom.com">C. Allen</a>, “<a href="http://tools.ietf.org/html/rfc2246">The TLS
            Protocol Version 1.0</a>,” RFC&nbsp;2246, January&nbsp;1999 (<a
                href="http://www.rfc-editor.org/rfc/rfc2246.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
        <td class="author-text"><a href="mailto:fielding@ics.uci.edu">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys,
            J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Frystyk, H.</a>,
            <a href="mailto:masinter@parc.xerox.com">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com">Leach,
                P.</a>, and <a href="mailto:timbl@w3.org">T. Berners-Lee</a>, “<a
                    href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,” RFC&nbsp;2616,
            June&nbsp;1999 (<a href="http://www.rfc-editor.org/rfc/rfc2616.txt">TXT</a>, <a
                    href="http://www.rfc-editor.org/rfc/rfc2616.ps">PS</a>, <a
                    href="http://www.rfc-editor.org/rfc/rfc2616.pdf">PDF</a>, <a
                    href="http://xml.resource.org/public/rfc/html/rfc2616.html">HTML</a>, <a
                    href="http://xml.resource.org/public/rfc/xml/rfc2616.xml">XML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC3339">[RFC3339]</a></td>
        <td class="author-text"><a href="mailto:GK@ACM.ORG">Klyne, G., Ed.</a> and <a
                href="mailto:chris.newman@sun.com">C. Newman</a>, “<a href="http://tools.ietf.org/html/rfc3339">Date and
            Time on the Internet: Timestamps</a>,” RFC&nbsp;3339, July&nbsp;2002 (<a
                href="http://www.rfc-editor.org/rfc/rfc3339.txt">TXT</a>, <a
                href="http://xml.resource.org/public/rfc/html/rfc3339.html">HTML</a>, <a
                href="http://xml.resource.org/public/rfc/xml/rfc3339.xml">XML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC3966">[RFC3966]</a></td>
        <td class="author-text">Schulzrinne, H., “<a href="http://tools.ietf.org/html/rfc3966">The tel URI for Telephone
            Numbers</a>,” RFC&nbsp;3966, December&nbsp;2004 (<a href="http://www.rfc-editor.org/rfc/rfc3966.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
        <td class="author-text"><a href="mailto:timbl@w3.org">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com">Fielding,
            R.</a>, and <a href="mailto:LMM@acm.org">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform
            Resource Identifier (URI): Generic Syntax</a>,” STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005 (<a
                href="http://www.rfc-editor.org/rfc/rfc3986.txt">TXT</a>, <a
                href="http://xml.resource.org/public/rfc/html/rfc3986.html">HTML</a>, <a
                href="http://xml.resource.org/public/rfc/xml/rfc3986.xml">XML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC4627">[RFC4627]</a></td>
        <td class="author-text">Crockford, D., “<a href="http://tools.ietf.org/html/rfc4627">The application/json Media
            Type for JavaScript Object Notation (JSON)</a>,” RFC&nbsp;4627, July&nbsp;2006 (<a
                href="http://www.rfc-editor.org/rfc/rfc4627.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC5246">[RFC5246]</a></td>
        <td class="author-text">Dierks, T. and E. Rescorla, “<a href="http://tools.ietf.org/html/rfc5246">The Transport
            Layer Security (TLS) Protocol Version 1.2</a>,” RFC&nbsp;5246, August&nbsp;2008 (<a
                href="http://www.rfc-editor.org/rfc/rfc5246.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC5322">[RFC5322]</a></td>
        <td class="author-text"><a href="mailto:presnick@qualcomm.com">Resnick, P., Ed.</a>, “<a
                href="http://tools.ietf.org/html/rfc5322">Internet Message Format</a>,” RFC&nbsp;5322, October&nbsp;2008
            (<a href="http://www.rfc-editor.org/rfc/rfc5322.txt">TXT</a>, <a
                    href="http://xml.resource.org/public/rfc/html/rfc5322.html">HTML</a>, <a
                    href="http://xml.resource.org/public/rfc/xml/rfc5322.xml">XML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC5646">[RFC5646]</a></td>
        <td class="author-text">Phillips, A. and M. Davis, “<a href="http://tools.ietf.org/html/rfc5646">Tags for
            Identifying Languages</a>,” BCP&nbsp;47, RFC&nbsp;5646, September&nbsp;2009 (<a
                href="http://www.rfc-editor.org/rfc/rfc5646.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC6125">[RFC6125]</a></td>
        <td class="author-text">Saint-Andre, P. and J. Hodges, “<a href="http://tools.ietf.org/html/rfc6125">Representation
            and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure
            Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</a>,” RFC&nbsp;6125, March&nbsp;2011
            (<a href="http://www.rfc-editor.org/rfc/rfc6125.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC6711">[RFC6711]</a></td>
        <td class="author-text">Johansson, L., “<a href="http://tools.ietf.org/html/rfc6711">An IANA Registry for Level
            of Assurance (LoA) Profiles</a>,” RFC&nbsp;6711, August&nbsp;2012 (<a
                href="http://www.rfc-editor.org/rfc/rfc6711.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC6749">[RFC6749]</a></td>
        <td class="author-text">Hardt, D., “<a href="http://tools.ietf.org/html/rfc6749">The OAuth 2.0 Authorization
            Framework</a>,” RFC&nbsp;6749, October&nbsp;2012 (<a
                href="http://www.rfc-editor.org/rfc/rfc6749.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC6750">[RFC6750]</a></td>
        <td class="author-text">Jones, M. and D. Hardt, “<a href="http://tools.ietf.org/html/rfc6750">The OAuth 2.0
            Authorization Framework: Bearer Token Usage</a>,” RFC&nbsp;6750, October&nbsp;2012 (<a
                href="http://www.rfc-editor.org/rfc/rfc6750.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC6819">[RFC6819]</a></td>
        <td class="author-text">Lodderstedt, T., McGloin, M., and P. Hunt, “<a
                href="http://tools.ietf.org/html/rfc6819">OAuth 2.0 Threat Model and Security Considerations</a>,” RFC&nbsp;6819,
            January&nbsp;2013 (<a href="http://www.rfc-editor.org/rfc/rfc6819.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="USA15">[USA15]</a></td>
        <td class="author-text"><a href="mailto:markdavis@google.com">Davis, M.</a>, <a href="mailto:ken@unicode.org">Whistler,
            K.</a>, and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex&nbsp;15, 09&nbsp;2009.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="W3C.REC-html401-19991224">[W3C.REC-html401-19991224]</a></td>
        <td class="author-text">Raggett, D., Hors, A., and I. Jacobs, “<a
                href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a>,” World Wide Web
            Consortium Recommendation&nbsp;REC-html401-19991224, December&nbsp;1999 (<a
                    href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="zoneinfo">[zoneinfo]</a></td>
        <td class="author-text">Public Domain, “<a href="http://www.twinsun.com/tz/tz-link.htm">The tz database</a>,”
            June&nbsp;2011.
        </td>
    </tr>
    </tbody>
</table>

<a name="rfc.references2"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<h3>19.2.&nbsp;Informative References</h3>
<table width="99%" border="0">
    <tbody>
    <tr>
        <td class="author-text" valign="top"><a name="JWK.Thumbprint">[JWK.Thumbprint]</a></td>
        <td class="author-text"><a href="mailto:mbj@microsoft.com">Jones, M.</a>, “<a
                href="http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint">JSON Web Key (JWK) Thumbprint</a>,”
            draft-jones-jose-jwk-thumbprint (work in progress), July&nbsp;2014 (<a
                    href="http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-01">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OAuth.Post">[OAuth.Post]</a></td>
        <td class="author-text">Jones, M. and B. Campbell, “<a
                href="http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html">OAuth 2.0 Form Post Response
            Mode</a>,” February&nbsp;2014.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OpenID.2.0">[OpenID.2.0]</a></td>
        <td class="author-text">OpenID Foundation, “OpenID Authentication 2.0,” December&nbsp;2007 (<a
                href="http://openid.net/specs/openid-authentication-2_0.txt">TXT</a>, <a
                href="http://openid.net/specs/openid-authentication-2_0.html">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OpenID.Basic">[OpenID.Basic]</a></td>
        <td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “<a
                href="http://openid.net/specs/openid-connect-basic-1_0.html">OpenID Connect Basic Client Implementer's
            Guide 1.0</a>,” November&nbsp;2014.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OpenID.Implicit">[OpenID.Implicit]</a></td>
        <td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “<a
                href="http://openid.net/specs/openid-connect-implicit-1_0.html">OpenID Connect Implicit Client
            Implementer's Guide 1.0</a>,” November&nbsp;2014.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OpenID.PAPE">[OpenID.PAPE]</a></td>
        <td class="author-text"><a href="mailto:david@sixapart.com">Recordon, D.</a>, <a
                href="mailto:mbj@microsoft.com">Jones, M.</a>, <a href="mailto:johnny.bufu@gmail.com">Bufu, J., Ed.</a>,
            <a href="mailto:cygnus@janrain.com">Daugherty, J., Ed.</a>, and <a href="mailto:n-sakimura@nri.co.jp">N.
                Sakimura</a>, “OpenID Provider
            Authentication Policy Extension 1.0,” December&nbsp;2008 (<a
                    href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.txt">TXT</a>, <a
                    href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">HTML</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="OpenID.Session">[OpenID.Session]</a></td>
        <td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “<a
                href="http://openid.net/specs/openid-connect-session-1_0.html">OpenID Connect Session Management 1.0</a>,”
            November&nbsp;2014.
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="RFC4949">[RFC4949]</a></td>
        <td class="author-text">Shirey, R., “<a href="http://tools.ietf.org/html/rfc4949">Internet Security Glossary,
            Version 2</a>,” RFC&nbsp;4949, August&nbsp;2007 (<a href="http://www.rfc-editor.org/rfc/rfc4949.txt">TXT</a>).
        </td>
    </tr>
    <tr>
        <td class="author-text" valign="top"><a name="X.1252">[X.1252]</a></td>
        <td class="author-text">International Telecommunication Union, “<a
                href="http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.1252-201004-I!!PDF-E&type=items">ITU-T
            Recommendation X.1252 -- Cyberspace security -- Identity management
            -- Baseline identity management terms and definitions</a>,” ITU-T&nbsp;X.1252, November&nbsp;2010.
        </td>
    </tr>
    </tbody>
</table>

<a name="AuthorizationExamples"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.A"></a>

<h3>Appendix A.&nbsp;
    Authorization Examples</h3>

<p>
    The following are non-normative examples of Authorization Requests with
    different <tt>response_type</tt> values and their responses
    (with line wraps within values for display purposes only):

</p>
<a name="codeExample"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.A.1"></a>

<h3>A.1.&nbsp;
    Example using response_type=code</h3>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /authorize?
    response_type=code
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &amp;scope=openid%20profile%20email
    &amp;nonce=n-0S6_WzA2Mj
    &amp;state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &amp;state=af0ifjsldkj
</pre>
</div>
<a name="id_tokenExample"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.A.2"></a>

<h3>A.2.&nbsp;
    Example using response_type=id_token</h3>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /authorize?
    response_type=id_token
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &amp;scope=openid%20profile%20email
    &amp;nonce=n-0S6_WzA2Mj
    &amp;state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz
    cyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4
    Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi
    bi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz
    MTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6
    ICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm
    ZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6
    ICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l
    eGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn
    spA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcip
    R2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac
    AAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5RZOQ0TLrOY
    u0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD
    4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDaQzUHl
    6cQQWNiDpWOl_lxXjQEvQ
    &amp;state=af0ifjsldkj
</pre>
</div>
<p>
    The value of the <tt>id_token</tt> parameter is the ID Token,
    which is a signed JWT,
    containing three base64url encoded segments separated by period ('.') characters.
    The first segment represents the JOSE Header.
    Base64url decoding it will result in the following set of Header Parameters:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {"kid":"1e9gdk7","alg":"RS256"}
</pre>
</div>
<p>
    The <tt>alg</tt> value represents the algorithm
    that was used to sign the JWT, in this case
    <tt>RS256</tt>, representing RSASSA-PKCS-v1_5 using SHA-256.
    The <tt>kid</tt> value is a key identifier used
    in identifying the key to be used to verify the signature.
    If the <tt>kid</tt> value is unknown to the RP,
    it needs to retrieve the contents of the OP's JWK Set again
    to obtain the OP's current set of keys.

</p>

<p>
    The second segment represents the Claims in the ID Token.
    Verifying and decoding the ID Token will yield the following Claims:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "gender": "female",
   "birthdate": "0000-10-31",
   "email": "janedoe@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }
</pre>
</div>
<p>
    The third segment represents the ID Token signature,
    which is verified as described in <a class="info" href="#JWS">[JWS]<span> (</span><span
        class="info">Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” July&nbsp;2014.</span><span>)</span></a>.

</p>
<a name="id_token-tokenExample"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.A.3"></a>

<h3>A.3.&nbsp;
    Example using response_type=id_token&nbsp;token</h3>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /authorize?
    response_type=id_token%20token
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &amp;scope=openid%20profile%20email
    &amp;nonce=n-0S6_WzA2Mj
    &amp;state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
    &amp;token_type=Bearer
    &amp;id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogIml
    zcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ
    4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiA
    ibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDE
    zMTEyODA5NzAsCiAiYXRfaGFzaCI6ICI3N1FtVVB0alBmeld0RjJBbnBLOVJ
    RIgp9.F9gRev0Dt2tKcrBkHy72cmRqnLdzw9FLCCSebV7mWs7o_sv2O5s6zM
    ky2kmhHTVx9HmdvNnx9GaZ8XMYRFeYk8L5NZ7aYlA5W56nsG1iWOou_-gji0
    ibWIuuf4Owaho3YSoi7EvsTuLFz6tq-dLyz0dKABMDsiCmJ5wqkPUDTE3QTX
    jzbUmOzUDli-gCh5QPuZAq0cNW3pf_2n4zpvTYtbmj12cVcxGIMZby7TMWES
    RjQ9_o3jvhVNcCGcE0KAQXejhA1ocJhNEvQNqMFGlBb6_0RxxKjDZ-Oa329e
    GDidOvvp0h5hoES4a8IuGKS7NOcpp-aFwp0qVMDLI-Xnm-Pg
    &amp;state=af0ifjsldkj
</pre>
</div>
<p>
    Verifying and decoding the ID Token will yield the following Claims:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "77QmUPtjPfzWtF2AnpK9RQ"
  }
</pre>
</div>
<a name="code-id_tokenExample"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.A.4"></a>

<h3>A.4.&nbsp;
    Example using response_type=code&nbsp;id_token</h3>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /authorize?
    response_type=code%20id_token
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &amp;scope=openid%20profile%20email
    &amp;nonce=n-0S6_WzA2Mj
    &amp;state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &amp;id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogIml
    zcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ
    4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiA
    ibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDE
    zMTEyODA5NzAsCiAiY19oYXNoIjogIkxEa3RLZG9RYWszUGswY25YeENsdEE
    iCn0.XW6uhdrkBgcGx6zVIrCiROpWURs-4goO1sKA4m9jhJIImiGg5muPUcN
    egx6sSv43c5DSn37sxCRrDZZm4ZPBKKgtYASMcE20SDgvYJdJS0cyuFw7Ijp
    _7WnIjcrl6B5cmoM6ylCvsLMwkoQAxVublMwH10oAxjzD6NEFsu9nipkszWh
    sPePf_rM4eMpkmCbTzume-fzZIi5VjdWGGEmzTg32h3jiex-r5WTHbj-u5HL
    7u_KP3rmbdYNzlzd1xWRYTUs4E8nOTgzAUwvwXkIQhOh5TPcSMBYy6X3E7-_
    gr9Ue6n4ND7hTFhtjYs3cjNKIA08qm5cpVYFMFMG6PkhzLQ
    &amp;state=af0ifjsldkj
</pre>
</div>
<p>
    Verifying and decoding the ID Token will yield the following Claims:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "c_hash": "LDktKdoQak3Pk0cnXxCltA"
  }
</pre>
</div>
<a name="code-tokenExample"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.A.5"></a>

<h3>A.5.&nbsp;
    Example using response_type=code&nbsp;token</h3>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /authorize?
    response_type=code%20token
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &amp;scope=openid%20profile%20email
    &amp;nonce=n-0S6_WzA2Mj
    &amp;state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &amp;access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
    &amp;token_type=Bearer
    &amp;state=af0ifjsldkj
</pre>
</div>
<a name="code-id_token-tokenExample"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.A.6"></a>

<h3>A.6.&nbsp;
    Example using response_type=code&nbsp;id_token&nbsp;token</h3>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  GET /authorize?
    response_type=code%20id_token%20token
    &amp;client_id=s6BhdRkqt3
    &amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &amp;scope=openid%20profile%20email
    &amp;nonce=n-0S6_WzA2Mj
    &amp;state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
    &amp;access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
    &amp;token_type=Bearer
    &amp;id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogIml
    zcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ
    4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiA
    ibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDE
    zMTEyODA5NzAsCiAiY19oYXNoIjogIkxEa3RLZG9RYWszUGswY25YeENsdEE
    iCn0.XW6uhdrkBgcGx6zVIrCiROpWURs-4goO1sKA4m9jhJIImiGg5muPUcN
    egx6sSv43c5DSn37sxCRrDZZm4ZPBKKgtYASMcE20SDgvYJdJS0cyuFw7Ijp
    _7WnIjcrl6B5cmoM6ylCvsLMwkoQAxVublMwH10oAxjzD6NEFsu9nipkszWh
    sPePf_rM4eMpkmCbTzume-fzZIi5VjdWGGEmzTg32h3jiex-r5WTHbj-u5HL
    7u_KP3rmbdYNzlzd1xWRYTUs4E8nOTgzAUwvwXkIQhOh5TPcSMBYy6X3E7-_
    gr9Ue6n4ND7hTFhtjYs3cjNKIA08qm5cpVYFMFMG6PkhzLQ
    &amp;state=af0ifjsldkj
</pre>
</div>
<p>
    Verifying and decoding the ID Token will yield the following Claims:

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "77QmUPtjPfzWtF2AnpK9RQ",
   "c_hash": "LDktKdoQak3Pk0cnXxCltA"
  }
</pre>
</div>
<a name="ExampleRSAKey"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.A.7"></a>

<h3>A.7.&nbsp;
    RSA Key Used in Examples</h3>

<p>
    The following RSA public key, represented in JWK format, can be used to
    validate the ID Token signatures in the above examples
    (with line wraps within values for display purposes only):

</p>

<div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>  {
   "kty":"RSA",
   "kid":"1e9gdk7",
   "n":"w7Zdfmece8iaB0kiTY8pCtiBtzbptJmP28nSWwtdjRu0f2GFpajvWE4VhfJA
        jEsOcwYzay7XGN0b-X84BfC8hmCTOj2b2eHT7NsZegFPKRUQzJ9wW8ipn_aD
        JWMGDuB1XyqT1E7DYqjUCEOD1b4FLpy_xPn6oV_TYOfQ9fZdbE5HGxJUzeku
        GcOKqOQ8M7wfYHhHHLxGpQVgL0apWuP2gDDOdTtpuld4D2LK1MZK99s9gaSj
        RHE8JDb1Z4IGhEcEyzkxswVdPndUWzfvWBBWXWxtSUvQGBRkuy1BHOa4sP6F
        KjWEeeF7gm7UMs2Nm2QUgNZw6xvEDGaLk4KASdIxRQ",
   "e":"AQAB"
  }
</pre>
</div>
<a name="Acknowledgements"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.B"></a>

<h3>Appendix B.&nbsp;
    Acknowledgements</h3>

<p>As a successor version of OpenID, this specification heavily relies
    on ideas explored in <a class="info" href="#OpenID.2.0">OpenID
        Authentication 2.0<span> (</span><span class="info">OpenID Foundation, “OpenID Authentication 2.0,” December&nbsp;2007.</span><span>)</span></a>
    [OpenID.2.0]. Please
    refer to Appendix C of OpenID Authentication 2.0 for the full list of
    the contributors for that specification.
</p>

<p>
    In addition, the OpenID Community would like to thank the following people for
    their contributions to this specification:

</p>

<p>
</p>
<blockquote class="text">
    <p>Naveen Agarwal (naa@google.com), Google
    </p>

    <p>Amanda Anganes (aanganes@mitre.org), MITRE
    </p>

    <p>Casper Biering (cb@peercraft.com), Peercraft
    </p>

    <p>John Bradley (ve7jtb@ve7jtb.com), Ping Identity
    </p>

    <p>Tim Bray (tbray@textuality.com), Google
    </p>

    <p>Johnny Bufu (jbufu@janrain.com), Janrain
    </p>

    <p>Brian Campbell (bcampbell@pingidentity.com), Ping Identity
    </p>

    <p>Blaine Cook (romeda@gmail.com), Independent
    </p>

    <p>Breno de Medeiros (breno@google.com), Google
    </p>

    <p>Pamela Dingle (pdingle@pingidentity.com), Ping Identity
    </p>

    <p>Vladimir Dzhuvinov (vladimir@nimbusds.com), Nimbus Directory Services
    </p>

    <p>George Fletcher (george.fletcher@corp.aol.com), AOL
    </p>

    <p>Roland Hedberg (roland.hedberg@adm.umu.se), University of Umea
    </p>

    <p>Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc.
    </p>

    <p>Edmund Jay (ejay@mgi1.com), Illumila
    </p>

    <p>Michael B. Jones (mbj@microsoft.com), Microsoft
    </p>

    <p>Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom
    </p>

    <p>Nov Matake (nov@matake.jp), Independent
    </p>

    <p>Chuck Mortimore (cmortimore@salesforce.com), Salesforce
    </p>

    <p>Anthony Nadalin (tonynad@microsoft.com), Microsoft
    </p>

    <p>Hideki Nara (hdknr@ic-tact.co.jp), Tact Communications
    </p>

    <p>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom
    </p>

    <p>David Recordon (dr@fb.com), Facebook
    </p>

    <p>Justin Richer (jricher@mitre.org), MITRE
    </p>

    <p>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.
    </p>

    <p>Luke Shepard (lshepard@fb.com), Facebook
    </p>

    <p>Andreas Åkre Solberg (andreas.solberg@uninett.no), UNINET
    </p>

    <p>Paul Tarjan (pt@fb.com), Facebook
    </p>
</blockquote>
<p>

</p>
<a name="Notices"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<a name="rfc.section.C"></a>

<h3>Appendix C.&nbsp;
    Notices</h3>

<p>Copyright (c) 2014 The OpenID Foundation.
</p>

<p>
    The OpenID Foundation (OIDF) grants to any Contributor, developer,
    implementer, or other interested party a non-exclusive, royalty free,
    worldwide copyright license to reproduce, prepare derivative works from,
    distribute, perform and display, this Implementers Draft or
    Final Specification solely for the purposes of (i) developing
    specifications, and (ii) implementing Implementers Drafts and
    Final Specifications based on such documents, provided that attribution
    be made to the OIDF as the source of the material, but that such attribution
    does not indicate an endorsement by the OIDF.

</p>

<p>
    The technology described in this specification was
    made available from contributions from various sources,
    including members of the OpenID Foundation and others.
    Although the OpenID Foundation has taken steps to help ensure
    that the technology is available for distribution, it takes
    no position regarding the validity or scope of any intellectual
    property or other rights that might be claimed to pertain to
    the implementation or use of the technology described in
    this specification or the extent to which any license under
    such rights might or might not be available; neither does it
    represent that it has made any independent effort to identify
    any such rights. The OpenID Foundation and the contributors
    to this specification make no (and hereby expressly disclaim any)
    warranties (express, implied, or otherwise), including implied
    warranties of merchantability, non-infringement, fitness for
    a particular purpose, or title, related to this specification,
    and the entire risk as to implementing this specification is
    assumed by the implementer. The OpenID Intellectual
    Property Rights policy requires contributors to offer
    a patent promise not to assert certain patent claims against
    other contributors and against implementers. The OpenID Foundation invites
    any interested party to bring to its attention any copyrights,
    patents, patent applications, or other proprietary rights
    that may cover technology that may be required to practice
    this specification.

</p>
<a name="rfc.authors"></a><br>
<hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right">
    <tbody>
    <tr>
        <td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td>
    </tr>
    </tbody>
</table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
    <tbody>
    <tr>
        <td class="author-text">&nbsp;</td>
        <td class="author-text">Nat Sakimura</td>
    </tr>
    <tr>
        <td class="author-text">&nbsp;</td>
        <td class="author-text">Nomura Research Institute, Ltd.</td>
    </tr>
    <tr>
        <td class="author" align="right">Email:&nbsp;</td>
        <td class="author-text"><a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a></td>
    </tr>
    <tr>
        <td class="author" align="right">URI:&nbsp;</td>
        <td class="author-text"><a href="http://nat.sakimura.org/">http://nat.sakimura.org/</a></td>
    </tr>
    <tr cellpadding="3">
        <td>&nbsp;</td>
        <td>&nbsp;</td>
    </tr>
    <tr>
        <td class="author-text">&nbsp;</td>
        <td class="author-text">John Bradley</td>
    </tr>
    <tr>
        <td class="author-text">&nbsp;</td>
        <td class="author-text">Ping Identity</td>
    </tr>
    <tr>
        <td class="author" align="right">Email:&nbsp;</td>
        <td class="author-text"><a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></td>
    </tr>
    <tr>
        <td class="author" align="right">URI:&nbsp;</td>
        <td class="author-text"><a href="http://www.thread-safe.com/">http://www.thread-safe.com/</a></td>
    </tr>
    <tr cellpadding="3">
        <td>&nbsp;</td>
        <td>&nbsp;</td>
    </tr>
    <tr>
        <td class="author-text">&nbsp;</td>
        <td class="author-text">Michael B. Jones</td>
    </tr>
    <tr>
        <td class="author-text">&nbsp;</td>
        <td class="author-text">Microsoft</td>
    </tr>
    <tr>
        <td class="author" align="right">Email:&nbsp;</td>
        <td class="author-text"><a href="mailto:mbj@microsoft.com">mbj@microsoft.com</a></td>
    </tr>
    <tr>
        <td class="author" align="right">URI:&nbsp;</td>
        <td class="author-text"><a href="http://self-issued.info/">http://self-issued.info/</a></td>
    </tr>
    <tr cellpadding="3">
        <td>&nbsp;</td>
        <td>&nbsp;</td>
    </tr>
    <tr>
        <td class="author-text">&nbsp;</td>
        <td class="author-text">Breno de Medeiros</td>
    </tr>
    <tr>
        <td class="author-text">&nbsp;</td>
        <td class="author-text">Google</td>
    </tr>
    <tr>
        <td class="author" align="right">Email:&nbsp;</td>
        <td class="author-text"><a href="mailto:breno@google.com">breno@google.com</a></td>
    </tr>
    <tr>
        <td class="author" align="right">URI:&nbsp;</td>
        <td class="author-text"><a href="http://stackoverflow.com/users/311376/breno">http://stackoverflow.com/users/311376/breno</a>
        </td>
    </tr>
    <tr cellpadding="3">
        <td>&nbsp;</td>
        <td>&nbsp;</td>
    </tr>
    <tr>
        <td class="author-text">&nbsp;</td>
        <td class="author-text">Chuck Mortimore</td>
    </tr>
    <tr>
        <td class="author-text">&nbsp;</td>
        <td class="author-text">Salesforce</td>
    </tr>
    <tr>
        <td class="author" align="right">Email:&nbsp;</td>
        <td class="author-text"><a href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a></td>
    </tr>
    <tr>
        <td class="author" align="right">URI:&nbsp;</td>
        <td class="author-text"><a href="https://twitter.com/cmort">https://twitter.com/cmort</a></td>
    </tr>
    </tbody>
</table>

<div id="cntvlive2-is-installed"></div>
</body>
</html>